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.
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: 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.
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: 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.
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.
"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 inclusion.
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 working installer/kernel!