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
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.
Xorg Locks up, system unresponsive.
Xorg starts correctly, and firstboot configuration tool starts in X allowing
you to configure settings.
WORKAROUND: Use VESA driver and Xorg starts correctly (missing firstboot
00:01.0 VGA compatible controller: S3 Inc. Savage 4 (rev 06) (prog-if 00
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.
Created attachment 136390 [details]
Xorg log of Savage 4
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:
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"
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.
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:
which has solved a certain numbers of "DRI" related issues with the
"savage" driver for me.
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
"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 :(
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
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.
Been in NEEDINFO since before 5.0, closing as INSUFFICIENT_DATA. Please test
and reopen if this is still an issue for you.
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