Bug 99528 - rhgb+kudzu gets stuck after "Probing for new hardware"
Summary: rhgb+kudzu gets stuck after "Probing for new hardware"
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: rhgb
Version: beta1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jonathan Blandford
QA Contact: Mike McLean
: 106183 (view as bug list)
Depends On:
Blocks: CambridgeBlocker
TreeView+ depends on / blocked
Reported: 2003-07-21 17:27 UTC by Denice
Modified: 2013-04-02 04:17 UTC (History)
8 users (show)

Clone Of:
Last Closed: 2003-10-10 13:56:09 UTC

Attachments (Terms of Use)

Description Denice 2003-07-21 17:27:48 UTC
Description of problem:
as per the release notes, my system hangs during the graphical boot (about 1/3
of the way thru at 'Probing for new hardware').  Toggling to VC 1 the last
message I see is:
 Enabling swap space..
whereas, using the nogui boot option, I would next see something about
'enabling IA-32 microcode update'

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

How reproducible:

Steps to Reproduce:
1. Do a default boot
Actual results:
system stays at graphical boot page forever

Expected results:
normal bootup

Additional info:
I see the following earlier in VC 1 also (in case it is related in any way)
 Unmounting initrd: umount /initrd: device is busy  [FAILED]

# lspci 
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:0d.0 Multimedia audio controller: Aureal Semiconductor Vortex 1 (rev 02)
00:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03)
00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X
(rev 5c)

Comment 1 Warren Togami 2003-08-07 09:35:12 UTC

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)

Comment 2 Don Vanco 2003-08-07 14:14:25 UTC
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...


Comment 3 Len Brown 2003-08-08 19:53:24 UTC
Does the hang go away if you boot with
'linux pci=noacpi' or 'linux acpi=off'

Comment 4 Denice 2003-08-14 11:32:55 UTC
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.

Comment 5 Ben Russo 2003-09-05 02:15:11 UTC
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 

Comment 6 Warren Togami 2003-09-20 20:54:44 UTC
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.

Comment 7 petrosyan 2003-09-20 23:57:14 UTC
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.

Comment 8 Bill Nottingham 2003-09-22 04:19:40 UTC
Yes, it's running on the same tty as X.

Comment 9 Bill Nottingham 2003-10-03 15:09:51 UTC
*** Bug 106183 has been marked as a duplicate of this bug. ***

Comment 10 Miloš Komarčević 2003-10-08 22:31:40 UTC
For me it doesn't get stuck, kudzu just takes a very long time (30+sec) in rhgb
compared to ~10 in text mode.

Comment 11 Miloš Komarčević 2003-10-10 09:22:58 UTC
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)

Comment 12 Ivo Sarak 2004-04-28 21:04:40 UTC
Same here?:

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