Bug 21805 - radeon-rewrite: crash in glCopyTexSubImage2D
Summary: radeon-rewrite: crash in glCopyTexSubImage2D
Status: RESOLVED WONTFIX
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/r300 (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-18 15:35 UTC by Stefan Dösinger
Modified: 2014-07-07 16:43 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Stefan Dösinger 2009-05-18 15:35:58 UTC
When running Team Fortress 2 in Wine with the DRI driver from the radeon-rewrite branch(with KMS et al set up), the game crashes in glCopyTexSubImage2D and in turn brings the X server down.

This is the backtrace I got from the crash:
=>0 0x7e1ce123 _generic_read_RGBA_span_BGRA8888_REV_SSE2+0xb3() in r300_dri.so (0x0032dca4)
  1 0x7e18d974 _swrast_read_rgba_span+0xe4(ctx=0x7d1e6950, rb=<register EDI not in topmost frame>, n=512, x=0, y=0, dstType=5121, rgba=) [/home/stefan/src/mesa/src/mesa/swrast/s_span.c:1585] in r300_dri.so (0x0033dce4)
  2 0x7e1a3ed0 read_color_image+0xc0(ctx=0x7d1e6950, x=0, y=0, type=5121, width=512, height=512) [/home/stefan/src/mesa/src/mesa/swrast/s_texstore.c:85] in r300_dri.so (0x0033dd34)
  3 0x7e1a426d _swrast_copy_texsubimage2d+0xad(ctx=<register EDI not in topmost frame>, target=3553, level=0, xoffset=0, yoffset=0, x=0, y=0, width=512, height=512) [/home/stefan/src/mesa/src/mesa/swrast/s_texstore.c:512] in r300_dri.so (0x0033dd94)
  4 0x7e120f79 _mesa_CopyTexSubImage2D+0x249(target=3553, level=0, xoffset=0, yoffset=0, x=0, y=0, width=512, height=512) [/home/stefan/src/mesa/src/mesa/main/teximage.c:3241] in r300_dri.so (0x0033dde4)
  5 0x7db4363e read_from_framebuffer_texture+0x19e(This=<register EDI not in topmost frame>, srgb=<is not available>) [/home/stefan/src/wine/linux/dlls/wined3d/../../../dlls/wined3d/surface.c:1048] in wined3d<elf> (0x0033de44)

<more wine code following>

The X server writes the following:
RADEON DRM CS failure - corruptions/glitches may occur -22
bufmgr: last submission : r:192 vs g:534769664 w:3356160 vs v:110455596

And then the screen seems dead. ssh still works

It may be possible that Wine calls glTexSubImage2D with a deleted texture name or the 0 texture bound. Team Fortress 2 releases the current rendertarget, and Wine does not handle this properly, resulting in complaints from the GL driver with other drivers. The logs indicate that I get the same errors back from Mesa, so this might be a red herring, and the crash occurs during a valid operation. In any case, the X server should not crash, no matter how badly the app behaves.
Comment 1 Jerome Glisse 2009-05-20 07:39:54 UTC
Any better with a more recent kernel & mesa checkout ?
Comment 2 Stefan Dösinger 2009-05-20 07:52:51 UTC
The kernel is David Airlie's radeon modeset kernel. Is there any newer kernel?

Mesa was the git version from yesterday, I'll retry it with your patches later today.
Comment 3 Jerome Glisse 2009-05-20 13:29:14 UTC
More fix were pushed in mesa radeon-rewrite branch would be nice if you could test with lastest commit.
Comment 4 Stefan Dösinger 2009-05-20 16:18:11 UTC
I'll retest tomorrow. I only had time for a r200 test session today.
Comment 5 Stefan Dösinger 2009-05-21 05:43:20 UTC
I've switched to your drm-next-radeon kernel branch(b1e6187f5ad3c8b836a68009006584337d914e99) and DDX driver(fba534017e581fcd9b9e49ba0b281fb500f576a7). The bug is different, but TF2 still does not start. I don't know yet if it is the same bug not. Mesa is updated to d7cc0eb47930d6c8ebfd18fefbe48fe8eec696a0.

The symptoms now are:
*) TF2 starts up and the driver complains(correctly) about invalid texture operations. TF2 continues startup, but the static loading background is not visible.

*) Without any obvious error message, the whole system slows down. TF2 doesn't crash, but I can move the mouse pointer only every other second and overall redraw is slow.

I can kill the X server via Ctrl+C(started it from an SSH connection). The framebuffer redraws properly. After an X server restart the server is still slow.

There are some suspicious messages in the dmesg. I'll try to get a log.
Comment 6 Nicolai Hähnle 2009-06-28 00:53:53 UTC
Do you still see this crash with current Mesa master after the merge?
Comment 7 Stefan Dösinger 2009-06-28 01:33:49 UTC
I'll have to retest. I am currently busy with other things unfortunately, so it will take a while before I have the time to update and retest.
Comment 8 Maciej Cencora 2009-12-19 07:38:06 UTC
It should be fixed on current mesa master branch (at least for r300-r500 gpus). Can you confirm?
Comment 9 Stefan Dösinger 2009-12-19 14:40:28 UTC
Same state as in my last comment unfortunately. My git xorg setup is fairly outdated, and I'll be away for the Christmas holidays.

In the meantime I have however updated my xorg git installation on my r250 card. That one has made big progress, but there are still a few more bugs to report. That's off-topic for this bug report though since TF2 won't run in Wine on that card. (Lack of a GL_ATI_fragment_shader based pixel shader backend)
Comment 10 Maciej Cencora 2010-03-07 13:26:56 UTC
(In reply to comment #9)
> Same state as in my last comment unfortunately. My git xorg setup is fairly
> outdated, and I'll be away for the Christmas holidays.
> 
> In the meantime I have however updated my xorg git installation on my r250
> card. That one has made big progress, but there are still a few more bugs to
> report. That's off-topic for this bug report though since TF2 won't run in Wine
> on that card. (Lack of a GL_ATI_fragment_shader based pixel shader backend)
> 

Can you try mesa/7.8 branch? There are a few r200 fixes, also it contains hw accelerated support for glCopyTex(Sub)Image, so the game should run much faster.
Comment 11 Andreas Boll 2014-07-07 16:43:36 UTC
The classic r300 driver has been abandoned long ago.
It was replaced by the Gallium driver r300g.

If you have issues with r300g please file a new bug report with component Drivers/Gallium/r300

Thanks.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.