From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 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): How reproducible: Always 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. Additional info:
May be related -- on a system with the same video chip, a colleague had their system freeze and noticed the following lines in /var/log/messages: Jan 8 15:28:25 youthoftoday firstboot: (==) Using config file: "/etc/X11/XF86Config" 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: Option "noaccel" 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 vesa driver? 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 MTRR bugfix. 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 there. TIA Uzi, TTYL
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. TIA
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. Thanks.