Red Hat Bugzilla – Bug 62160
tuxracer hangs when esd running
Last modified: 2008-05-01 11:38:01 EDT
Description of Problem:
Hampton beta 3 (aka Skipjack)
Under GNOME tuxracer works but without any sound. Enabling esd enables sound in
tuxracer, but about after 5-10 seconds of racing the program freezes. The
computer as a whole is not locked--I am able to switch to a VT and the command
killall -4 tuxracer kills the program successfully. It is necessary to restart
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. enable esd
2. run tuxracer
Graphics card is a Radeon 7500. DRI is enabled.
It works for me with matrox graphic card and ATI Rage Mobility M4. Please try
tuxracer-0.61-8 on ftp::/people.redhat.com/than/rawhide if it works.
To debug this problem i need a strace output of tuxracer. just do strace -o tuxracer.log
Please attach your X server log, X config file, and /var/log/messages
file to the report. Make sure these files are from *after* a lockup/hang.
Once I've gotten the files, I'll troubleshoot this and try to find a solution.
I'll see if I can recreate this for Milan beta 4. I'll be on the road until
Friday, August 2, so it won't be before then.
Some additional notes, however, that I have noticed that leads me to believe
that this might be a problem associated more with the radeon driver under SMP
than this particular game:
(1) when using the SMP kernel, X sometimes hangs when the screensaver kicks in
(my guess is that it is hanging during some of the GL screensavers)
(2) tuxracer works fine on the same hardware using the uniproc kernel, both with
and without sound
I should also note that tuxracer works fine on the same hardware under SMP both
with and without sound if I replace the Radeon 7500 with a GeForce 3 and use
NVIDIA's drivers--again, I think this points towards an SMP issue with the
radeon driver in XFree86.
... but I'll still try to recreate the problem and generate the necessary logs.
My primary systems run Radeon hardware exclusively except when testing
other hardware/debugging. Both main systems are SMP machines. I never
encounter any problems with either machine when using Radeon hardware.
I just did a 2 hour tuxracer binge in RHL 7.3 with no lockups on a
Radeon 7500, dual 1Ghz P-III Xeon, with a Tyan S2567 HEsl motherboard.
It sounds to me like you're encountering a sound card driver DMA lockup
There are known screensaver-causes-X-to-crash problems that are not
hardware specific, and those are fixed in rawhide in the latest
kernel release (DRM locking fixes from Tim Smith).
Sounds like your soundcard driver might not be SMP clean to me.
Is there any chance you could swap sound cards to one that uses
a different driver just to test that theory?
In 8.0 final I can't get tuxracer to run with sound so I've been unable to
reproduce this particular problem. That said, I do get repeatable hard lockups
of the system when using radeon, DRI, and SMP. I've removed all PCI cards (sound
card included) and this doesn't help. My next thought is that maybe this is a
Serverworks agpgart issue but it seems to work fine for you.
The lockup issue (outside of tuxracer) still happens with the recent errata
kernel for 8.0.
I've setup netdump and netdump-server but when the system locks no crash dumps
are sent. I think this may have to do with the fact that the system locks
completely, including the network layer.
Basically, I'm stumped. At this point I could care less about tuxracer and more
about just having a system that stays up when running SMP and DRI.
the last update basically describes the issue in 71738. Feel free to close this
and track that issue, as it is a more accurate description of the problem at
My machine has a Serverworks chipset also. While that sucks
performancewise for 3D, it does work.
Are you running a completely updated system with up2date et al?
Have you tried RHL 8.0+updates by chance?
There will be new XFree86 updates coming for 7.3 before long also.
Closing as WORKSFORME, as I have no problems with tuxracer. If this problem
still occurs for you in RHL 8.0, feel free to reopen with details and I'll
investigate it again.