Bug 51735 - XFree86 locks up machine hard using Revolution IV card and SGI flatpanel
Summary: XFree86 locks up machine hard using Revolution IV card and SGI flatpanel
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 7.1
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Mike A. Harris
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-08-14 15:38 UTC by Need Real Name
Modified: 2007-04-18 16:35 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2002-02-15 16:35:29 UTC
Embargoed:


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

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

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
hard.

How reproducible:
Sometimes

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
specific.

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 13:41:29 UTC
Attach X server logs and configs using the link below.

Comment 2 Need Real Name 2001-08-15 21:08:31 UTC
Created attachment 28033 [details]
XF86Config file.

Comment 3 Need Real Name 2001-08-15 23:45:42 UTC
Created attachment 28074 [details]
X server log

Comment 4 Mike A. Harris 2001-08-20 03:23:46 UTC
Attach your /var/log/messages after a crash.

Comment 5 Need Real Name 2001-08-30 18:10:39 UTC
Created attachment 30214 [details]
/var/log/messages after a crash.

Comment 6 Mike A. Harris 2002-02-09 22:37:11 UTC
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 16:35:23 UTC
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
stable.

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 12:56:31 UTC
Assuming erratum release fixed the problem as above.

Thanks.


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