Bug 137804 - X freezes after a while (or immediately) when playing 3D games
Summary: X freezes after a while (or immediately) when playing 3D games
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11   
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-11-01 16:13 UTC by Nils Philippsen
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-11 21:48:36 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 1959 None None None Never

Description Nils Philippsen 2004-11-01 16:13:55 UTC
Build Identifier: 

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).

Reproducible: Always
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
Actual Results:  
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

Expected Results:  
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:


Comment 1 Nils Philippsen 2004-11-01 16:15:54 UTC
Changing severity to high ("Critical?") as lets X crash/hang -- Bugzilla beta2
didn't let me enter "Critical" directly.

Comment 2 Zenon Panoussis 2004-11-04 12:09:35 UTC
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. 

Comment 3 Nils Philippsen 2004-11-04 13:13:02 UTC
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
or not?

Comment 4 Zenon Panoussis 2004-11-04 15:13:51 UTC
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

Comment 5 Zenon Panoussis 2004-11-04 15:44:15 UTC
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. 

Comment 6 Nils Philippsen 2004-12-01 14:24:25 UTC
this bug is tracked now at https://bugs.freedesktop.org/show_bug.cgi?id=1924

Comment 7 Nils Philippsen 2004-12-01 14:30:02 UTC
Bah. It's https://bugs.freedesktop.org/show_bug.cgi?id=1959 actually.

Comment 8 Zenon Panoussis 2004-12-07 10:00:09 UTC
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... 

Comment 9 Mike A. Harris 2004-12-07 10:31:13 UTC
Nils:  How are your heat sinks holding out?  :o)

Comment 10 Nils Philippsen 2004-12-07 12:15:11 UTC
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).

Comment 11 Mike A. Harris 2005-02-11 21:48:36 UTC
Ok, we're now tracking this bug in the X.Org bugzilla, so 
setting status to "UPSTREAM".


Note You need to log in before you can comment on or make changes to this bug.