Cairo using the GLX glitz backend locks X. This has been confirmed by another user. Cairo 0.9.2 Glitz 0.4.4 Radeon 9500 Pro cvs drm as of 8/19
Created attachment 2940 [details] testcase cairo glitz backend testcase hardlocks r300
Confirmed by me :) Setup: distro: Gentoo cairo 0.9.2-r1 glitz 0.4.4 cvs drm/mesa/xorg of 8/19
Created attachment 2941 [details] my xorg.conf
Created attachment 2966 [details] [review] drm side of the proposed fix Is bitblt secure?
Created attachment 2967 [details] [review] r300 driver side of the proposed fix
(In reply to comment #4) > Created an attachment (id=2966) [edit] > drm side of the proposed fix > > Is bitblt secure? Not as-is. But it's a type3 packet so that's already handled by radeon_check_and_fixup_packet3.
Created attachment 2968 [details] [review] Whops... :)
I can confirm that the r300 driver patch works.
(In reply to comment #4) > Created an attachment (id=2966) [edit] > drm side of the proposed fix > > Is bitblt secure? I don't think so - it could be used to view system memory, so a check is needed.
I may have spoken a little too soon. Now instead of an immediate hard lock after some time the machine locks.
(In reply to comment #9) > (In reply to comment #4) > > > > Is bitblt secure? > > I don't think so - it could be used to view system memory, > so a check is needed. See comment #6.
(In reply to comment #11) > (In reply to comment #9) > > (In reply to comment #4) > > > > > > Is bitblt secure? > > > > I don't think so - it could be used to view system memory, > > so a check is needed. > > See comment #6. Thing is the patch switches BITBLT to use a r300 raw packet, so this would bypass usual radeon checks. I am not certain why this patch affects things at all, as I would have expected packets inherited from radeon driver to work fine - certainly Xserver should use BITBLT quite often. Perhaps, there is some subtle issue that I am missing ?
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #9) > > > (In reply to comment #4) > > > > > > > > Is bitblt secure? > > > > > > I don't think so - it could be used to view system memory, > > > so a check is needed. > > > > See comment #6. > > Thing is the patch switches BITBLT to use a r300 raw packet, so this would > bypass usual radeon checks. Usual readeon checks arent used for r300 as far as I can see. Looking at radeon_check_and_fixup_packet3, it seems to me like LOAD_VBPNTR would go trough it without any checks. > > I am not certain why this patch affects things at all, as I would have expected > packets inherited from radeon driver to work fine - certainly Xserver should > use BITBLT quite often. Perhaps, there is some subtle issue that I am missing ? Remember that xorg uses indirect buffers.
(In reply to comment #10) > I may have spoken a little too soon. Now instead of an immediate hard lock after > some time the machine locks. Is this always reproducible? If so r300 based gpus might work better with page flipping or without buffer swaps. Also you should be able to workaround this "bug" by starting with atis drivers before using r300 driver.
This is reproducible although I'm no longer sure it is directly related to cairo (or anything opengl). If I load the drm.ko and radeon.ko modules, after a while, I get the freeze. Enabling page flipping didn't seem to solve the issue. I'm not sure if the following backtrace is useful but here it is anyway: gdb) bt #0 0xffffe410 in ?? () #1 0xbfe964f8 in ?? () #2 0x00000000 in ?? () #3 0x00006444 in ?? () #4 0xb7d69539 in ioctl () from /lib/libc.so.6 #5 0x080dbbb6 in xf86ioctl () #6 0xb7f76828 in drmCommandNone () from /usr/lib/xorg/modules/linux/libdrm.so #7 0xb7977943 in RADEONWaitForIdleCP () from /usr/lib/xorg/modules/drivers/radeon_drv.so #8 0xb7799afc in XAAInit () from /usr/lib/xorg/modules/libxaa.so #9 0x080f6edf in miInitializeBackingStore () #10 0x0810d446 in miSpriteInitialize () #11 0x080825e6 in DoGetImage () #12 0x08082896 in ProcGetImage () #13 0x0808594b in Dispatch () #14 0x0806dddc in main () I'll try to provide further information if necessary. (Sorry for the late response as this is the first time I've had access since Hurricane Katrina)
Comment on attachment 2940 [details] testcase wrong file?!
(In reply to comment #16) > (From update of attachment 2940 [details] [edit]) > wrong file?! It seems to me like this would be the infamous r300 lock case. Im going to disable r300 support to avoid confusion with stable and not stable chips. As far as the bitblt part goes, r300_cmdbuf.c needs to be converted to pass along drm_file_t so that we can call radeon_check_and_fixup_packet3(...).
Fixed in DRM CVS thanks to Dave Airlie. File in another bug about the r300 chip instability if you wish.
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.