Bug 113533 - System hangs on X start/stop with Trident Blade 3D
Summary: System hangs on X start/stop with Trident Blade 3D
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: XFree86
Version: 3.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-01-14 23:57 UTC by Joshua Uziel
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-02-01 09:38:44 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Joshua Uziel 2004-01-14 23:57:34 UTC
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:

Comment 1 Joshua Uziel 2004-01-17 06:28:03 UTC
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)

Comment 2 Mike A. Harris 2004-01-17 06:49:19 UTC
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

Comment 3 Mike A. Harris 2004-01-17 06:51:37 UTC
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

Comment 4 Joshua Uziel 2004-01-23 02:58:01 UTC
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.

Comment 5 Mike A. Harris 2004-02-17 08:04:47 UTC
Any additional info to report?

Comment 6 Joshua Uziel 2004-02-17 08:18:13 UTC
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.

Comment 7 brandon 2004-10-07 01:20:22 UTC
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.  

Comment 9 Mike A. Harris 2005-02-01 09:38:44 UTC
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.


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