Bug 51735 - XFree86 locks up machine hard using Revolution IV card and SGI flatpanel
XFree86 locks up machine hard using Revolution IV card and SGI flatpanel
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
Depends On:
  Show dependency treegraph
Reported: 2001-08-14 11:38 EDT by Need Real Name
Modified: 2007-04-18 12:35 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-02-15 11:35:29 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XF86Config file. (2.26 KB, text/plain)
2001-08-15 17:08 EDT, Need Real Name
no flags Details
X server log (21.91 KB, text/plain)
2001-08-15 19:45 EDT, Need Real Name
no flags Details
/var/log/messages after a crash. (26.63 KB, text/plain)
2001-08-30 14:10 EDT, Need Real Name
no flags Details

  None (edit)
Description Need Real Name 2001-08-14 11:38:53 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-12 i686; en-US; rv:0.9.1)

Description of problem:
While using Revolution IV cards and the SGI 1600SW flat panel display,
restarting X (logging out, or killing X) occasionally locks the machine up

How reproducible:

Steps to Reproduce:
1.Launch X
2.After an extended period of time, log out of X (or kill it)

Actual Results:  The machine often locks up hard.  Since the monitor does
not use stardard VGA output, it does not recieve signal from the machine
after the lockup, so you cannot check for kernel messages

Expected Results:  X should have restarted.

Additional info:

So far I've only tested this with Dell Precision 420 workstations and the
revolution IV cards.  I have other machines available for testing if you'd
like be to do any further investigation.

We have a large number of these machines with this particular setup, so the
crash is not machine specific (probably not flakey hardware).

These machines were stable with Redhat 6.2 and 7.0.  The issue didn't start
until redhat 7.1, and it continues with the roswell beta.  The problem
didn't occur with redhat 6.2 with xfree86 4.0.3, so it's probably not X

I tried running 7.1 with the 2.2.19 kernel, so it's not 2.4 specific.

Perhaps the new glibc?
Comment 1 Mike A. Harris 2001-08-15 09:41:29 EDT
Attach X server logs and configs using the link below.
Comment 2 Need Real Name 2001-08-15 17:08:31 EDT
Created attachment 28033 [details]
XF86Config file.
Comment 3 Need Real Name 2001-08-15 19:45:42 EDT
Created attachment 28074 [details]
X server log
Comment 4 Mike A. Harris 2001-08-19 23:23:46 EDT
Attach your /var/log/messages after a crash.
Comment 5 Need Real Name 2001-08-30 14:10:39 EDT
Created attachment 30214 [details]
/var/log/messages after a crash.
Comment 6 Mike A. Harris 2002-02-09 17:37:11 EST
I recommend updating to our current erratum kernel and XFree86, etc.
and seeing if that solves the problem.  XFree86-4.1.0-15 has been
released for RHL 7.1
Comment 7 Need Real Name 2002-02-15 11:35:23 EST
I've applied the new XFree86 RPMs and the latest kernel RPM, and test machines
appear to be stable.  I'll send confirmation in a week or so if they're still

As a sidenote, I attempted to debug the old kernel/X by logging over null modem
to another machine, and the machines didn't report any errors when they crashed.
Comment 8 Mike A. Harris 2002-03-07 07:56:31 EST
Assuming erratum release fixed the problem as above.


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