Description of problem: System hangs on boot at "Initializing hardware ..." Version-Release number of selected component (if applicable): 2.6.11-1.27_FC3 i686 How reproducible: always Steps to Reproduce: 1. boot with grub stanza containing "kernel /vmlinuz-2.6.11-1.27_FC3 ro root=LABEL=/ vga=ext" 2. 3. Actual results: System prints out -- Starting udev: Initializing hardware ... Disabling IRQ #10 Expected results: I expected system to boot and run, just like it did with the 2.6.9 kernels. Additional info: Had no problem with earlier FC3 kernels (notably the 2.6.9-xxx series). Not sure if my problems started w/ 2.6.10 or 2.6.11. I can run if I specify "noapic apm=off acpi=off usb=off" in the boot options. (Found references to these options in other Bugzilla listings -- #138916 and #151319.) Fairly certain 'usb=off' doesn't affect the results. Haven't had time to play with the others to see which one really fixes the problem. System is IBM Netfinity 4500R: * single 733MHz P-III processor * 512MB of memory * ServeRAID-3L card * 2nd ethernet card (LNE100TX -- uses 'tulip' driver) # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 8 model name : Pentium III (Coppermine) stepping : 3 cpu MHz : 731.418 cache size : 256 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 mmx fxsr sse bogomips : 1441.79 # lspci 00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 05) 00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 05) 00:01.0 VGA compatible controller: S3 Inc. Savage 4 (rev 04) 00:02.0 Ethernet controller: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] (rev 44) 00:09.0 SCSI storage controller: IBM SCSI RAID Adapter [ServeRAID] (rev 0d) 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 4f) 00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04) 01:03.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 01:03.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 01:05.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev 20)
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
The system still hangs for 22 minutes during the "storage" portion of the "Initializing hardware" phase. 1) Upgraded (yum update) to the new "2.6.12-1.1372_FC3" kernel. 2) Configured the following boot stanza for grub: ------------------------------------------------- title Fedora Core (2.6.12-1.1372_FC3) BOOTS SLOW. REQUIRES INTERVENTION. root (hd0,0) kernel /vmlinuz-2.6.12-1.1372_FC3 ro root=LABEL=/ vga=ext initrd /initrd-2.6.12-1.1372_FC3.img 3) Modified /etc/rc.d/sysinit to record some times during rc.sysinit: ---------------------------------------------------------------------- # diff rc.sysinit rc.sysinit.ORIG 168,170d167 < echo "" < echo -n " load_module: $1 @ `date +%H:%M:%S` " < #lsmod 172d168 < #lsmod 222,227d217 < < echo "" < echo -n " PRESS RETURN TO CONTINUE @ `date +%H:%M:%S` :" < read junk_var < date < # 4) Reboot the system and see the following: -------------------------------------------- Starting udev: [ OK ] Initializing hardware... load_module: ips @ 16:46:20 load_module: aic7xxx @ 16:46:20 Disabling IRQ #10 load_module: aic7xxx @ 16:58:18 load_module: ips @ 16:58:18 load_module: floppy @ 16:58:18 storage load_module: eth0 @ 16:58:18 load_module: eth1 @ 16:58:18 load_module: tulip @ 16:58:18 load_module: pcnet32 @ 16:58:18 network audio load_module: i2c-piix4 @ 16:58:19 load_module: ohci-hcd @ 16:58:19 done [ OK ] PRESS RETURN TO CONTINUE @ 16:58:19 : 5) I do not know why the aic7xxx module is getting loaded twice, but this seems to be where the problem lies -- as there is a 22 minute gap here. (Reproduced the 22 min. figure on two separate boot cycles.) Let me know if you need more info. - Don
its probably being loaded once for each controller.. 01:03.0 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) 01:03.1 SCSI storage controller: Adaptec AIC-7899P U160/m (rev 01) I'll ask upstream to take a look, hopefully someone there has an idea why its taking so long. Do you have anything connected to those controllers at all ?
can you attach a full dmesg from after its booted please ?
Created attachment 117471 [details] output from dmesg(8) Output from dmesg.
Nothing is connected to the Adaptec controller channels. I can see why 'aic7xxx' might get loaded twice (once for each channel, 'scsi1' and 'scsi2'), but then I get curious as to why 'ips' [scsi0] is loaded twice, too. I'm not sure what all the "irq 10" messages are trying to tell me. Also, now that I can see all the SCSI ABORT and RESET messages associated with 'scsi2', I can see why it might be taking so long to start up. It might actually be the hardware is the root problem (just bad luck it coincided with a kernel update). (If I had easy access to a spare mainboard, I could try exchanging it, but there isn't one available right now.)
This is a mass-update to all currently open Fedora Core 3 kernel bugs. Fedora Core 3 support has transitioned to the Fedora Legacy project. Due to the limited resources of this project, typically only updates for new security issues are released. As this bug isn't security related, it has been migrated to a Fedora Core 4 bug. Please upgrade to this newer release, and test if this bug is still present there. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. Thank you.
This is a mass-update to all currently open kernel bugs. A new kernel update has been released (Version: 2.6.15-1.1830_FC4) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. Thank you.
Closing per previous comment.