Bug 175784 - "MP-BIOS bug: 8254 timer not connected to IO-APIC" on IBM HS40 w/RHEL4 update 2
"MP-BIOS bug: 8254 timer not connected to IO-APIC" on IBM HS40 w/RHEL4 update 2
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Brian Maly
Brian Brock
:
Depends On:
Blocks: 193520
  Show dependency treegraph
 
Reported: 2005-12-14 17:22 EST by John Caruso
Modified: 2013-01-30 12:29 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-09-25 01:58:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Caruso 2005-12-14 17:22:11 EST
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 17:24:46 EST
Sorry, that should have been "see also bug 172920" (not 17920).
Comment 3 Konrad Rzeszutek 2006-11-03 15:47:57 EST
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-06 21:07:49 EST
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 14:36:14 EST
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 14:42:44 EST
Re: Comment #5, The boot arg "disable_timer_pin_1" and "disable_8254_timer" may
also help.
Comment 7 Brian Maly 2007-02-16 16:57:38 EST
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 09:37:52 EST
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 11:37:43 EST
Did the boot args help? 
Comment 10 Konrad Rzeszutek 2007-05-11 13:41:51 EDT
John, ping?
Comment 11 John Caruso 2007-05-11 13:49:22 EDT
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 12:32:01 EDT
FYI, Bug 235761 reports a similar problem with FC7.
Comment 13 Brian Maly 2007-07-15 21:40:20 EDT
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 01:58:34 EDT
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.

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