|Summary:||"MP-BIOS bug: 8254 timer not connected to IO-APIC" on IBM HS40 w/RHEL4 update 2|
|Product:||Red Hat Enterprise Linux 4||Reporter:||John Caruso <jcaruso>|
|Component:||kernel||Assignee:||Brian Maly <bmaly>|
|Status:||CLOSED WONTFIX||QA Contact:||Brian Brock <bbrock>|
|Version:||4.0||CC:||darford, drussell, jbaron, jvillalo, konradr, maurizio.antillon|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-09-25 05:58:34 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description John Caruso 2005-12-14 22:22:11 UTC
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).
Comment 1 John Caruso 2005-12-14 22:24:46 UTC
Sorry, that should have been "see also bug 172920" (not 17920).
Comment 3 Konrad Rzeszutek 2006-11-03 20:47:57 UTC
HS40 are Intel blades actually. There are none in the Westford lab. Thought Geoff might know of some. Adding him on this BZ.
Comment 4 Darlene J. Ford 2007-01-07 02:07:49 UTC
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.
Comment 5 Brian Maly 2007-02-16 19:36:14 UTC
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.
Comment 6 Brian Maly 2007-02-16 19:42:44 UTC
Re: Comment #5, The boot arg "disable_timer_pin_1" and "disable_8254_timer" may also help.
Comment 7 Brian Maly 2007-02-16 21:57:38 UTC
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.
Comment 8 Darlene J. Ford 2007-02-17 14:37:52 UTC
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.
Comment 9 Brian Maly 2007-02-28 16:37:43 UTC
Did the boot args help?
Comment 10 Konrad Rzeszutek 2007-05-11 17:41:51 UTC
Comment 11 John Caruso 2007-05-11 17:49:22 UTC
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).
Comment 12 Darlene J. Ford 2007-07-04 16:32:01 UTC
FYI, Bug 235761 reports a similar problem with FC7.
Comment 13 Brian Maly 2007-07-16 01:40:20 UTC
Can someone confirm this problem exists in RHEL4.5 or RHEL4.6? If this has been fixed, then this bug should be closed.
Comment 14 Brian Maly 2008-09-25 05:58:34 UTC
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.