Red Hat Bugzilla – Bug 113533
System hangs on X start/stop with Trident Blade 3D
Last modified: 2007-11-30 17:07:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5)
Description of problem:
On an x86_64 system with a Trident Blade 3D (PCI Vendor ID 0x1023,
Device ID 0x9880) running RHEL3, starting and/or stopping (not certain
at this point) X can cause the system to hang completely.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Log into a text console on the system as root
2. while true; do init 5; sleep 15; init 3; sleep 15; done
3. Let it go for a little while and eventually the system will be
completely hung with nothing showing on the screen.
May be related -- on a system with the same video chip, a colleague
had their system freeze and noticed the following lines in
Jan 8 15:28:25 youthoftoday firstboot: (==) Using config file:
Jan 8 15:28:25 youthoftoday firstboot: (WW) TRIDENT(0):
Failed to set up write-combining range (0xfe000000,0x800000)
Only certain models of Radeon, Nvidia, and Matrox have been
officially tested on our RHEL/AMD64 release. All other video
drivers are provided basically as a convenience for users, and
to find out which ones have problems, etc. Nonetheless, I try
to support everything as best I can wherever possible.
I don't have this hardware available (on any architecture), so
I'll need you to experiment a bit to try to determine if this
is a driver problem, or an X server, or perhaps even kernel
problem. Is the problem reproduceable also if you use:
in the X config file device section, and do a full system reboot
to reset the video hardware to power on clean defaults, then
start X up, and try your above test?
If that makes it go away, we can follow that trouble path. If it
persists though, can you try testing the "vesa" driver instead
of the 'trident' driver? Does the problem occur also with the
Please attach your X server log and config file from the
original problem case scenario as individual uncompressed
file attachments, including the *.old logs. A copy of
/var/log/messages from after a crash session would be useful
also, in case there are kernel clues which might be relevant.
One other important detail, is which AMD64 motherboard are you
using? There are some known problems with a Tyan 2885 board,
which there are BIOS updates for, and a forthcoming kernel
If we can nail it to the driver we can narrow it down a bit
further, and can compare with the current CVS driver as well.
Attach the above tidbits, and we'll see where we can go from
doh, we had a mid-air collision on my submit...
What model/brand of motherboard is the second system using?
Another option to try on both systems is Option "NoMTRR" to
see if that improves stability at all. If it does, I suspect
Tyan, and the MTRR problem perhaps, but that's speculative as
I don't know the mobo hardware yet.
Done a bit of testing so far... looks like the "noaccel" option made
no difference, but using the "vesa" driver instead of the "trident"
driver does seem to be doing the trick. I'll update the bug with more
info as I get it.
Any additional info to report?
Not really. The vesa driver did seem to take care of things, so
further investigation into the trident driver's issue hasn't taken
place. Do what you will with the bug, it was mostly my intention of
putting it here for tracking purposes. If I dig any further and have
more information, I'll update the bug, but I suspect it won't too high
a priority for me.
I am having the same problem problem with an ati radeon card however,
I have not yet installed the system. I boot the system from the
install cd. Anaconda correctly probes my video card as an Radeon
9600. When the graphical screen starts to appear, the entire screen
is diplayed as white, with a mouse curser on the screen. It sits like
this for several seconds, and then hangs, still displaying a white
screen with a mouse curser.
Setting bug status to "CURRENTRELEASE" using "vesa" driver, as
per comment #6. If the issue persists with current X in the
future with trident driver, please report the issue to X.org
via http://bugs.freedesktop.org and hopefully the trident
driver maintainer can reproduce the issue and suggest a fix.