Running OpenGL programs like blender, xscreensaver (e.g. bouncing cow) and occasionally glxgears hangs the system when DRI is loaded. The mouse still moves, alt-sysrq still works and I can still ssh into the box. XMMS also keeps playing. Of the programs in trouble (X and bouncingcow/glxgears/...) I can usually kill only one. The other remains running at 99% CPU and goes to 99% CPU zombie mode when I try to SIGKILL it. It is not entirely predictable: Blender (when loading a complicated scene) seems to always hang immediately, bouncingcow hangs almost always, but not when run directly as the only program from startx, and glxgears usually runs fine and never hangs immediately. I verified the problem on linux 2.6.14 with both xorg 6.8.99.903 and 6.8.2. I suspect xorg 6.8.1 with linux 2.4.x had the same problem. (I cannot verify that though, as I don't have that setup anymore.) When the offending programs die, I occasionally get these messages (over ssh, as my monitor locks up): ~% DISPLAY=:0.0 glxgears r200WaitIrq: drmRadeonIrqWait: -16 ~% DISPLAY=:0.0 xscreensaver-demo r200WaitIrq: drmRadeonIrqWait: -16 Not loading the "dri" module or setting "RenderAccel" to False fixes the problem, but obviously also makes any 3d program unusably slow. I have put my xorg.conf, Xorg.0.log, kernel config and the output of lspci -vx online at http://student.science.uva.nl/~rturk/X/
Any improvements using a current version of xorg?
(In reply to comment #1) > Any improvements using a current version of xorg? I'm not the original submitter, but with the latest Debian Xorg server (version 7.0.14) i've experienced the same lock with the same error message (r200WaitIrq: drmRadeonIrqWait: -16). I'm going to attach my Xorg config and log, i'll be glad to help fix this one, so if you need some other info ask freely. (=
Created attachment 5433 [details] X 7.0.0 /var/log/Xorg.0.log
Created attachment 5434 [details] Xorg config
(In reply to comment #1) > Any improvements using a current version of xorg? No. I didn't get around to hijacking my fathers laptop to be able to check with ssh yet, but it still hangs in exactly the same way AFAICS. I attached my new /var/log/Xorg.0.log, although dri is disabled in it. I'm also running the prebuilt wacom_drv.so from linuxwacom 0.7.3, in case that might matter. I will of course try without wacom loaded, or with cvs versions of X if that seems useful.
Created attachment 5435 [details] Xorg log
Are you using the kernel-supplied dri or modules from dri.freedesktop.org?
(In reply to comment #7) > Are you using the kernel-supplied dri or modules from dri.freedesktop.org? The kernel-supplied one.
Try to build the modular one as it's where the development of dri is at. http://dri.freedesktop.org/wiki/Building See section 1.1.1 how to build it. I would also recommend upgrading to mesa cvs and see if it makes a difference.
(In reply to comment #9) > I would also recommend upgrading to mesa cvs and see if it makes a difference. I've followed the instructions on the wiki (everything but the kernel DRM modules) , so with the CVS build glxgears seems to works. I've also tried a couple of games (Foobillard and Tremulous) and basically all the OpenGL xscreensaver hacks, all work ok, except "bouncingcow", now i can see the cow, but if i try to move the window X hangs.
Could you please try to get a backtrace of the hang. Please see: http://xorg.freedesktop.org/wiki/DebuggingTheXserver
I've tried to run Xorg with gdb attached, but when it hangs there's no SIGSEGV, i can still move the mouse, but for the rest X is frozen. I've created the same a backtrace, but don't know if it could be useful. If i could be of any help, ask freely. P.S. i've only recompiled the DRI module and libGL/libGLU libraries with debug symbols, not yet tried to do the same for the complete Xorg monster, i should look first if Debian has Xorg packages with debug symbols prebuilt. (=
Created attachment 5559 [details] Xorg backtrace
A backtrace is usually not useful for a hardware hang such as this case; it just shows the software spinning in some place where it's waiting for the hardware to catch up. Unfortunately, that doesn't tell us anything about why the hardware hangs. Hangs when running certain 3D apps are usually caused by Mesa driver issues, but it'd be interesting to know whether using the DRM from DRI CVS and/or Option "AccelMethod" "EXA" makes a difference.
I've tried all the permutations (enabled/disabled EXA and CVS/Debian DRM kernel driver) but no improvement. The "bouncing cow" demo hangs X if everytime i move the window. I've found that i can hang X resizing the glxdemo window too. (=
Does Option "RenderAccel" "off" make a difference? Also, do you have non-empty /etc/drirc and/or ~/.drirc files?
The system /etc/drirc is missing and i've done the all tests with a dummy account without a ~/.drirc. I've tried RenderAccel on and off with and without EXA, still bouncing cow hangs. Should i use driconf and tweak some parameter?
I believe it is a duplicate of bug #1280 https://bugs.freedesktop.org/show_bug.cgi?id=1280
You are probably right, disabling TCL (setting "Use software TCL pipeline" with driconf) the bouncing cow demo doesn't hang X anymore.
(In reply to comment #19) > You are probably right, disabling TCL (setting "Use software TCL pipeline" with > driconf) the bouncing cow demo doesn't hang X anymore. I still had a hang after disabling TCL in .drirc, in gl-117. It seems to happen much more seldom, though (it used to crash after some minutes, max. half an hour, and this was the only hang in 3 days).
I've tried yesterday the OpenGL screen hacks enabling the HW TCL and the "bouncing cow" doesn't hang X anymore. I'm running the latest Debian kernel (2.6.17-8) and the Xorg version 7.1.1 (this one is from Debian experimental), the ATI Xorg driver is labeled as 1:6.6.2-1. I've tried with both the unstable (6.4.2-1.1) and experimental (6.5.0.cvs.20060524-1) Debian MESA libraries, and with both no more hangs, but for example with Google Earth, there are some artifacts on the OpenGL rendered graphics using the 6.4.2-1.1 MESA libs. This doesn't happen with the experimental version of the MESA libraries. If you need some other info, feel free to ask. Thanks for your help.
Remi, can you confirm Andrea's findings?
(In reply to comment #22) > Remi, can you confirm Andrea's findings? not yet at least I'm afraid: I'm running Arch Linux, so I don't have all those nice development packages ready for downloading and probably won't have time to compile everything myself until the weekend :(
(In reply to comment #22) > Remi, can you confirm Andrea's findings? Yes I can! ~% uname -r 2.6.17.13 ~% pacman -Q xorg xf86-video-ati mesa xorg 11R7.0-1 xf86-video-ati 6.6.2-2 mesa 6.5.1rc2-1 I wasn't able to crash X with bzflag (some 15 minutes I guess), blender (working with a large file which used to hang X instantly) and bouncingcow (2 hours). I'll try to run lots of OpenGL programs the next few weeks, but for now everything seems to work fine! Thanks a lot! :)
Thank you for following up Remi. Closing per submitter, please reopen if you hit this again.
*** Bug 2999 has been marked as a duplicate of this bug. ***
Mass version move, cvs -> git
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.