Description of problem: After a stock install of RHEL4u2 on a IBM HS40 8839-61X blade, the system prints the following error during bootup: Uncompressing Linux... Ok, booting the kernel. MP-BIOS bug: 8254 timer not connected to IO-APIC As per the Redhat HCL entry at this URL...: https://hardware.redhat.com/hwcert/show.cgi?id=157078 ...the HS40 (8839) is certified with RHEL4. So it would seem that it shouldn't exhibit a problem like this. Also, as additional background, the boots frequently hang--usually at "Checking for new hardware" (kudzu) but sometimes at "Initializing hardware... storage network audio" (see also bug 17920)--and the system keeps configuring and unconfiguring the keyboard on successive reboots (on those boots where kudzu doesn't hang). The kudzu hangs occur whether or not SAFE=yes is set in /etc/sysconfig/kudzu. So although I'm only calling out the IO-APIC error in this bug, it appears that RHEL4u2 doesn't boot well on the IBM HS40. How reproducible: Install RHEL4u2 on an IBM HS40, reboot it, and watch the boot messages. Additional info: An apparent workaround is to specify "noapic" in the kernel boot line (the 8254 timer error message goes away, anyway, though I don't know if this is a good solution).
Sorry, that should have been "see also bug 172920" (not 17920).
HS40 are Intel blades actually. There are none in the Westford lab. Thought Geoff might know of some. Adding him on this BZ.
Getting same error MP-BIOS bug: 8254 timer not connected to IO-APIC on a Compaq PC with an AMD Athlon 64 processor Fedora Core 5 with kernel 2.6.18-1.2200.fc5 after upgrading the BIOS to v. 3.11 I note that FC5 did boot with the original BIOS that came with the machine. However, Red Hat Graphical Boot and Windows XP appear to operate correctly with the new BIOS.
Does the system appear to work properly regardless of the error? Does booting with "enable_8254_timer" as a boot arg make a difference? Many different chipsets have problems with timer routing over the 8254 (ATI, NVidia and Serverworks most notably). About the keyboard error, are any errors written to the log? Or is it just a kudzu message? I have a patch I can adapt that may solve this issue. The IBM blades have a USB kvm, so when the system boots the keyboard may or may not be there.
Re: Comment #5, The boot arg "disable_timer_pin_1" and "disable_8254_timer" may also help.
Looks like this system has a ServerWorks chipset which is known to have this issue. This issue was fixed in later RHEL4 release, so trying a newer kernel is suggested.
Yes, my HP PC does have the NVIDIA chipset. I've verified that I have the latest BIOS. The system does not boot Fedora 5 with the default arguments at all. It will not boot Knoppix with the default arguments, but will boot in debug mode. Excuse me while I log out of windows and try the recommended boot args.
Did the boot args help?
John, ping?
Still here, but I haven't run into this issue anymore--primarily because in the 1.5 years since I initially reported this issue most of these HS40s have been repurposed (and in fact few of them are even running Linux now).
FYI, Bug 235761 reports a similar problem with FC7.
Can someone confirm this problem exists in RHEL4.5 or RHEL4.6? If this has been fixed, then this bug should be closed.
Closing as WONTFIX since we cant confirm this issue still exists. There were many changes in this code in later RHEL4 releases so it is very likely fixed (we saw this problem a lot and now we dont on other hardware). Please re-open this bug if anyone discovers the problem still exists in the newest RHEL4 release.