Red Hat Bugzilla – Bug 137804
X freezes after a while (or immediately) when playing 3D games
Last modified: 2007-11-30 17:10:53 EST
When I play 3D games, X freezes after a while (when playing torcs --
torcs.sourceforge.net -- freshly compiled for Rawhide) or even immediately (when
trying to play tuxracer), glxgears works without crashing. My wife reported that
some 3D screensavers also freeze X (don't know which).
Steps to Reproduce:
(0. Configure system to use DRI)
1. run tuxracer or torcs (can provide packages if so desired)
1a. if playing torcs, play for a while
X freezes. Logging in remotely gives (with torcs):
- torcs-bin eats 100% of the CPU
- stracing the torcs-bin process gives that it constantly does an ioctl (haven't
remembered which, but can check if needed) on the /dev/dri/card0 file descriptor
- when killing torcs-bin, the X process eats up 100% of the CPU
- although it is listed as running ("R") in `ps auxwww|grep X`, it can't be
killed nor can the display be restored by any other means than rebooting
I can play torcs, tuxracer, whatever without X crashing.
The graphics card is an ATI FireGL 8800, I use the radeon driver included in
xorg-x11. The relevant versions are:
Changing severity to high ("Critical?") as lets X crash/hang -- Bugzilla beta2
didn't let me enter "Critical" directly.
I have the same problem without playing games. Starting openoffice or
changing between mozilla windows is sometimes enough to make the
machine freeze completely, so that the only remedy is the reset
button. There is no trace of anything in the logs, nor can I isolate
the problem. Theoretically it could be anything, including hardware,
but this only started with FC3beta3 and it never happens at runlevel
3. ATI Rage 128 II pro, vendorId: 1002, deviceId: 5446 in hwconfig.
Zenon, does this freeze your machine (i.e. the Linux kernel) or "only"
X? I.e. is the machine reachable from the network, can you log into it
All other machines here are headless and I was too lazy to move the
monitor to test network login, but I will next time. In the meanwhile
I see a relation between high I/O load and X freezing. I am unable to
finish mke2fs -c /big/partition or dd if=/dev/urandom
of=/big/partition without freezing, while the exact same things work
fine in RL3.
Occasionally X crashes and restarts instead of freezing. I'm beginning
to feel lucky crashing because at least that saves me from the reset
OK, I logged in from the network and provoked the freeze with dd. It's
total and absolute, which means that we're probably looking at
completely different problems. My freezes and my crashes could also be
unrelated to each-other. There's no beginning to figuring it out, so
I'll just stop feeding the bugs and see if they go away by themselves.
this bug is tracked now at https://bugs.freedesktop.org/show_bug.cgi?id=1924
Bah. It's https://bugs.freedesktop.org/show_bug.cgi?id=1959 actually.
The bug behind comment #2 has been resolved. It was a huge amount of
fat filth tightly packed between the CPU heat sink blades, causing the
CPU to overheat. When the CPU finally got toasted and replaced and the
heat sink was cleaned, the problem went away. The coincidence with the
upgrade is probably an indicator of higher CPU loads in FC3 than in FC2.
Oh, well. I guess the "stop feeding it" approach worked pretty well,
in a way...
Nils: How are your heat sinks holding out? :o)
Mike: My heat sinks are doing perfectly, thanks for asking ;-). I've
updated the fdo-BZ entry because I couldn't reproduce the problem with
xorg-x11-6.8.1-12.FC3.21 -- I'll check whether it's really resolved
for soem time and then close it and this bug as well (if so).
Ok, we're now tracking this bug in the X.Org bugzilla, so
setting status to "UPSTREAM".