Distribution: FC3 Hardware Environment: Compaq Proliant DL580, 4 PIII Software Environment: kernel 2.6.10-1.770_FC3smp Problem Description: boot failure Steps to reproduce: boot smp kernel Non-smp kernel works without 'pci=noapic' or 'noapic'. [root@yew ~]# uname -a Linux ahost.adomain.com 2.6.10-1.770_FC3smp #1 SMP Thu Feb 24 14:20:06 EST 2005 i686 i686 i386 GNU/Linux [root@yew ~]# lspci 00:00.0 Host bridge: ServerWorks CNB20HE Host Bridge (rev 23) 00:00.1 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01) 00:00.2 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01) 00:00.3 Host bridge: ServerWorks CNB20HE Host Bridge (rev 01) 00:03.0 System peripheral: Compaq Computer Corporation Advanced System Management Controller 00:04.0 RAID bus controller: LSI Logic / Symbios Logic 53C1510 (rev 02) 00:05.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC 215IIC [Mach64 GT IIC] (rev 7a) 00:07.0 PCI bridge: Intel Corp. 80960RP [i960 RP Microprocessor/Bridge] (rev 05) 00:07.1 Memory controller: Intel Corp. 80960RP [i960RP Microprocessor] (rev 05) 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 51) 00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage IIC 215IIC [Mach64 GT IIC] (rev 7a) 02:05.0 PCI Hot-plug controller: Compaq Computer Corporation PCI Hotplug Controller (rev 12) 07:05.0 PCI Hot-plug controller: Compaq Computer Corporation PCI Hotplug Controller (rev 12) 07:06.0 PCI bridge: Intel Corp. 21154 PCI-to-PCI Bridge 07:07.0 PCI bridge: Intel Corp. 21154 PCI-to-PCI Bridge 08:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 08:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 09:04.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 09:05.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08)
How does acpi=noirq? And could you please get the dmesg through a serial console for the failure case?
Yes, I will get console output when I return. It is hard to plug in the serial cable from 800+ miles away. I have not lost interest, only colocation.
Created attachment 5159 [details] Capture of console to serial port without apic params - hang Captured from boot using following in grub.conf. Results in system hang. Must force power off. kernel /vmlinuz-2.6.11-1.14_FC3 ro root=/dev/VolGroup00/LogVol00 rhgb console=tty0 console=ttyS0,38400n8 debug
Created attachment 5160 [details] Console serial port capture with apic param - no hang pci=routeirq noapic console=tty0 console=ttyS0,38400n8 debug
Adding 'lapic' appears to correct the problem. I am running: pci=routeirq noapic lapic Is this an acceptable fix, or is there something lurking?
boot params are a workaround, not a fix -- so if you need any then it is a bug. still an issue in 2.6.13?
You might want to check bug 4700. http://bugzilla.kernel.org/show_bug.cgi?id=4700 There you'll find a reference to http://www.ussg.iu.edu/hypermail/linux/kernel/0502.1/1450.html which has a patch that works on my laptop with a similar problem (need to boot with "noapic").
What is the most recent SMP+IOAPIC kernel that works with no boot parameters? With 2.6.13 are any boot prameters needed? In particular, is pci=routeirq necessary, and is it sufficient, or does it also still need noapic lapic? Re: comment #7 -- I think that this is a different issue.
I have not tried 2.6.13. I have only been taking the kernels pushed by FC3. I have never seen an SMP kernel work on this machine without lapic nopic. 2.6.12 requires lapic and nopic. Using pci=routeirq is not neccessary, nor is it sufficient, noapic lapic is needed on 2.6.12. Also, perhaps unrelated, anytime I use 'shutdown -r' under SMP the following hang results. Non-SMP will reboot successfully. NMI - CPU Bus Parity Error
Is it possible to boot this system with "acpi=off" and see if it can come up with the IOAPIC enabled in MPS mode? If yes, please attach the dmesg and /proc/interrupts Also, please be sure that CONFIG_NR_CPUS= a large number, say 32.
ping for update from bug reporter...
please re-open if this is reproducible with a recent kernel.