Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 99528
Summary: | rhgb+kudzu gets stuck after "Probing for new hardware" | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux Beta | Reporter: | Denice <deatrich> |
Component: | rhgb | Assignee: | Jonathan Blandford <jrb> |
Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> |
Severity: | high | Docs Contact: | |
Priority: | high | ||
Version: | beta1 | CC: | aoliva, ddumas, kreg, mitr, notting, petrosyan, p.van.egdom, wtogami |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-10-10 13:56:09 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 100643 |
Description
Denice
2003-07-21 17:27:48 UTC
kernel-2.6.0-0.test2.1.29 kernel-2.4.21-20.1.2024.2.1.nptl Severn with these two kernels consistently get stuck after "Probing for hardware" during the graphical boot. The system does not lockup, I can still move mouse and change to VT1, but it does not proceed further. The same kernels booting in text mode work fine. Hardware: Athlon Palomino 1GHz 256KB cache Sony Vaio FXA-36 VIA KT133A chipset 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) 01:00.0 Class 0300: 1002:4c4d (rev 64) If it matters, I experienced this hang after initial install, however, upon rebooting and going into single user mode a single time I am now able to boot "normally" (i.e. graphical works). Hardware details: Compaq Armada E500 I believe it has some Intel chipset and is "Microsoft ACPI compliant" - whatever that means... Don Does the hang go away if you boot with 'linux pci=noacpi' or 'linux acpi=off' This comment relates to the first system in the list, with the 'lspci' listing. I probably can't be of much further help on this bug, since I now believe that my hardware is flakey - which is to say that flakey hardware may result in the graphical boot screen blocking normal startup. That isn't very helpful. I can no longer reproduce the problem when I re-install Severn. But at the same time, the on-board sound card is no longer visible (despite being enabled in the bios). When I first installed Severn and was playing around the on-board sound capability WAS seen and showed up in modules.conf, though it did not work when configured by the installer or by config-redhat-soundcard. Another flakey aspect of the machine is that the mouse insists on behaving badly when firstboot runs - one has to toggle out and back into graphics to get the mouse to behave. By comparison, I have another oldish, almost identical node that I dug out and installed with Severn. It is the same model, with the same 'lspci' listing. (The only difference is an additional ide-zip device instead of the additional ide-cdwriter device.) I have no problems with this machine at all - it sees the onboard sound card, and the exact same mouse on it does not exhibit strange firstboot behaviour. There is no graphical boot hang when doing a default, fresh workstation install. Both machines are Dell Optiplex GX1's. Additional info: BIOS settings are and always have been: ACPI: off Power Mngt: disabled As a side note, this onboard sound card is only configured properly by sndconfig. I'll search through bugzilla to see if this already reported for this sound card. The second pci sound card (vortex) which shows up in the lspci listing isn't supported, I believe. Removing it from the system doesn't change the behaviour of the systems with respect to this bug id. So I guess I will salvage parts from it, and throw the box and motherboard on the junk heap. I have seen this happen on two other machines, a Compaq Pro(whatever) desktop with a fast P4 and a Whitebox with an MSI motherboard and a Celeron. I never saw it happen when doing a full power cycle, just when doing a shutdown -r I figured out something... this happens 100% in cases where kudzu's text menu would appear. If this happens, then I CTRL-ALT-Backspace to kill X, then ALT-F7, I see a very corrupted looking kudzu window that is frozen. This behavior persists through current Rawhide on two of my systems. I can confirm the same behavior as described in previos comment. I managed to read what the corrupted looking kudzu window says: The following mouse has been removed from your system: Generic Mouse (PS/2) You can choose to: 1) ... 2) ... 3) ... ...... ------------------------- I never get that kudzu window when I boot with "nogui" kernel command line option. Yes, it's running on the same tty as X. *** Bug 106183 has been marked as a duplicate of this bug. *** For me it doesn't get stuck, kudzu just takes a very long time (30+sec) in rhgb compared to ~10 in text mode. Works normally for me now with rhgb-0.10.2-1, kudzu-1.1.32-1 and initscripts-7.36-2 I still have the issue of PCMCIA 3c59x w/ rhgb, but that's another bug (#100470 perhaps, or maybe I should open a new one) |