Bug 206710 - Xorg Locks up with S3 Savage 4 card after install during firstboot/probe
Xorg Locks up with S3 Savage 4 card after install during firstboot/probe
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: xorg-x11-drv-savage (Show other bugs)
5.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Adam Jackson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-15 16:15 EDT by Shawn Starr
Modified: 2008-08-02 19:40 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-30 17:06:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg log of Savage 4 (56.12 KB, text/plain)
2006-09-15 16:15 EDT, Shawn Starr
no flags Details
Xorg log of SuperSavage/IXC 64 (23.40 KB, text/plain)
2006-10-15 08:45 EDT, Joachim Frieben
no flags Details

  None (edit)
Description Shawn Starr 2006-09-15 16:15:57 EDT
Description of problem: S3 Savage 4 GPU wedges Xorg when X has started after 
probing hardware during firstboot.


Version-Release number of selected component (if applicable):

X Window System Version 7.1.1
Release Date: 12 May 2006
X Protocol Version 11, Revision 0, Release 7.1.1
Build Operating System: Linux 2.6.9-34.ELsmp i686 Red Hat, Inc.

Xorg driver: xorg-x11-drv-savage-2.1.1-5.fc6

How reproducible:
Install RHEL5B1 installs fine, reboot, during firstboot when X video is 
probed, Xorg locks up.


Steps to Reproduce:
1. Install RHEL5B1, Reboot
2. When system comes up to do firstboot: probes video card, starts X 
initially, then Xorg locks up hard, have to hard poweroff. Cannot ssh into 
box. GPU appears wedged.

Actual results:
Xorg Locks up, system unresponsive.


Expected results:
Xorg starts correctly, and firstboot configuration tool starts in X allowing 
you to configure settings.

Additional info:

WORKAROUND: Use VESA driver and Xorg starts correctly (missing firstboot 
settings however)

hardware information:

00:01.0 VGA compatible controller: S3 Inc. Savage 4 (rev 06) (prog-if 00 
[VGA])
        Subsystem: IBM Unknown device 01c5
        Flags: bus master, medium devsel, latency 248, IRQ 255
        Memory at feb80000 (32-bit, non-prefetchable) [size=512K]
        Memory at f0000000 (32-bit, prefetchable) [size=128M]
        [virtual] Expansion ROM at 50000000 [disabled] [size=64K]
        Capabilities: [dc] Power Management version 2

Box type:       Product Name: IBM eserver xSeries 220 -[864641X], 1GB Ram

Attached is the Xorg log from the failed startup using the savage driver.
Comment 1 Shawn Starr 2006-09-15 16:15:57 EDT
Created attachment 136390 [details]
Xorg log of Savage 4
Comment 4 Joachim Frieben 2006-09-27 17:23:06 EDT
This happens -still- for "Fedora rawhide" as of 2006-09-27 on my "IBM
ThinkPad T23" which sports a "SuperSavage/IXC 64". I think disabling
"DRI" in "xorg.conf" after booting to single user mode would have done
the job, too. No need to switch to the "vesa" driver.
It's likely that this bug would also benefit from the driver update that
I had suggested in:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195851#c6

It has solved a major "DRI" problem of the "savage" driver. After installing
the system, boot to single user mode, update the driver package and continue.
As far as "firstboot" is concerned, you should be able to relaunch it by
setting the content of "/etc/sysconfig/firstboot" to "RUN_FIRSTBOOT=YES"
and similar.
Comment 5 Joachim Frieben 2006-09-27 17:28:36 EDT
I forgot to mention that in the scenario described above, the "firstboot"
settings entered by the user are actually retained. So, there is no need
to rerun "firstboot" anyway.
Comment 6 Joachim Frieben 2006-10-15 08:04:58 EDT
I do still experience "firstboot" problems on my "IBM ThinkPad T23".
After setting the required system parameters, "firstboot" quits and
tries to launch the "X" server. The system is caught in an endless
loop of trying to start the server, blanking the screen and so on.
Fortunately, I can login from a remote system and trigger the reboot.
Otherwise the system would hang completely. I strongly suggest to
incorporate the patch from:

  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196011#c21

which has solved a certain numbers of "DRI" related issues with the
"savage" driver for me.
Comment 7 Joachim Frieben 2006-10-15 08:45:10 EDT
Created attachment 138528 [details]
Xorg log of SuperSavage/IXC 64

Hm, looking at the "Xorg.0.log" file, I am rather skeptical if
I really observe a related issue. On the other hand, the "Lost
VT_WAITACTIVE race" message is certainly something to look at
,too.
Comment 8 Joachim Frieben 2006-10-25 13:05:10 EDT
"Lost VT_WAITACTIVE race" issue with "SuperSavage/IXC 64" still
present in "FC6" final. This is a nasty bug because it cannot be
fixed in the installer a posteriori :(
Comment 9 RHEL Product and Program Management 2006-10-26 16:10:03 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 10 Adam Jackson 2006-12-18 13:00:25 EST
This sounds like the VT_WAITACTIVE race, which should be resolved when the RC
goes out.  Please test, and reopen if further problems are encountered.
Comment 12 Adam Jackson 2007-05-30 17:06:51 EDT
Been in NEEDINFO since before 5.0, closing as INSUFFICIENT_DATA.  Please test
and reopen if this is still an issue for you.
Comment 13 Joachim Frieben 2007-05-31 05:27:27 EDT
I cannot install "RHEL5" on my "IBM ThinkPad T23" because the 2.6.18 kernel
included in this distribution is **busted** as far as the "IDE" disk interface
is concerned. The system simply freezes at some point during the install when
disk traffic is high. Very disappointing since this issue was already known back
in 2006 and solved in the "Fedora" tree in early 2007. I hope to be able to
report about the situation as soon as "U1" is released, then hopefully with a
working installer/kernel!

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