Bug 175784

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>
Severity:	low	Docs Contact:
Priority:	medium
Version:	4.0	CC:	darford, drussell, jbaron, jvillalo, konradr, maurizio.antillon
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-09-25 05:58:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	193520

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

John, ping?

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.