Bug 187411

Hello,

I also have the exact problem (..MP-BIOS bug: 8254 timer not connected to IO-APIC
)running FC5 on an hp laptop. Previously I did not see this message while
running FC4. I tried acpi=off while the message disappeared but I got.....

atiixp: codec read timeout (reg 0)
atiixp: codec read timeout (reg 1c)

happening multiple times when I ran dmesg.see attachment3 [details]-dmesg-acpi-off.

I have attached some dmesg outputs and also a "cat /proc/interrupts" output
showing clock slightly off.

hope this info helps,

Created attachment 127291 [details]
dmesg

Created attachment 127293 [details]
dmesg with acpi-off specified in grub

Created attachment 127294 [details]
cat /proc/interrupts showing timer mismatch

Created attachment 127296 [details]
computer setup

Created attachment 127315 [details]
text file specifications

output of lspci -vv and cat /proc/interrupts while running the non-buggy
kernel-2.6.15-1.1833_FC4-i686

Should I try to get demsg by running the newer kernel and turning off acpi ?
Just to see if I get similar results ?

Created attachment 127485 [details]
running buggy kernel with noapic flag

This is the output of dmesg and cat /proc/interrupts when booting
kernel-2.6.16-1.2069_FC4-i686 with noapic flag

Everything seems to work ok with this setting.

Comment on attachment 127485 [details]
running buggy kernel with noapic flag

This is the output of dmesg and cat /proc/interrupts when booting
kernel-2.6.16-1.2069_FC4-i686 with noapic flag

Everything seems to work ok with this setting ... no more ..MP-BIOS bug warning
when booting.

Do those boxes have updated BIOSes? Having to use noapic usually means buggy
BIOS/legacy hardware.

Could you say which HP laptop it is exactly? Model and BIOS version would help.

Hello ,

Laptop specs,

HP Pavilion ZV5346us
ROMPag BIOS (up to date) F.45
512 mb ram (128 mb shared with ATi 9100IGP video card.
FC5 kernel-smp-2.6.16-1.2080_FC5.i686.

My dmesg attachments seems to indicate a problem when ATI board is detected. I
also noticed that cpuspeed no longer works.

I am reinstalling FC4 at the moment to see if I will have the same problem. I
had FC4 on before I upgraded and did not have the MP-BIOS bug problem.

restarted laptop with noapic flag (FC5 configuration above) MP-BIOS message
disappeared but got the following message :

Starting udev : disabling IRQ 5.

then machine froze at:

Starting bluetooth services [ok].

I had to use the power button to shut down machine.

A similar thing happened to me ... and it froze on bluetooth as well. I was able
to Ctrl-Alt-F1 and change the grub.config accordingly. But it's strange that it
didn't happen the first time I used the noapic flag, only the second time.

My laptop is a Sony Vaio PCG-GRT100
BIOS Phoenix WinPhlash for VAIO

My BIOS was updated about 2 years ago ... however, it seems there is no newer
update. This is the only update released, and I updated to it 2 years ago:
http://esupport.sony.com/perl/swu-download.pl?mdl=PCGGRT100&upd_id=1412&os_id=7

I've an HP zx5030EA (ATI chipset, F.43 BIOS) and I see this message. I've only
ever seen it with FC5; never with FC3. As far as I'm aware, there's been no ill
effect and all the interrupts are going through the IO-APIC and LAPIC OK (under
FC3, I had to boot an SMP kernel to get IO-APIC support otherwise the IRQ
routing would've been a mess).

dmesg log includes:

ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...  failed.
...trying to set up timer as Virtual Wire IRQ... works.

Does this machine even have an i8254? Doesn't the LAPIC supercede this chip?
Typical /proc/interrupts reads:

           CPU0
  0:     972673  local-APIC-edge  timer
  1:       3093    IO-APIC-edge  i8042
  5:     156268   IO-APIC-level  ATI IXP, ATI IXP Modem
  7:          2    IO-APIC-edge  parport0
  8:          1    IO-APIC-edge  rtc
 12:        144    IO-APIC-edge  i8042
 14:      31112    IO-APIC-edge  ide0
 15:      34022    IO-APIC-edge  ide1
 16:          1   IO-APIC-level  yenta
 17:     347478   IO-APIC-level  yenta, ohci_hcd:usb3, ohci1394,
radeon@pci:0000:01:05.0
 18:      95925   IO-APIC-level  ohci_hcd:usb1, ohci_hcd:usb2, ehci_hcd:usb5, eth0
 19:         49   IO-APIC-level  ohci_hcd:usb4
 21:      14027   IO-APIC-level  acpi
NMI:          0
LOC:     972592
ERR:          0
MIS:          0

The same error but a bit different story.

At first everything worked fine (2.6.15-1.2054_FC5). Both x86 and x86_64
kernels. I tried both version to see which one works better. Finnaly I've opted
for x86. I have AMD64 MSI RS480 chipset machine.

I have a dual-boot computer (Linux and Windows). Once I restarted computer from
within Windows and when Linux was going up I received this error:

MP-BIOS bug: 8254 timer not connected to IO-APIC

I suspected that something went wrong with installatin first and tried to
reinstall it but strangely enough I was not able to do this also. The setup get
stuck in some moment. It just freezes.

This bug also happens with kernel-2.6.16-1.2111_FC5 on
Toshiba Satellite L25-S1192

I just updated the BIOS to the latest version (April 2006 version) and the bug
is still there.

Ani,

Could you try using the SMP kernel?

this still happens with SMP kernel. Attaching the dmesg output.

Created attachment 128832 [details]
dmesg output

I am now pretty sure that the BIOS is to blame. The newer kernels fixed a
different problem on my desktop computer (the system time running twice normal
speed on SMP kernel), but broke support for BIOS on my notebook. My notebook
won't even boot on kernels newer than 2.6.15-1.2054_FC5. The problem is that you
don't exactly know what the BIOS update fixes and what it doesn't.

this bug still happens with kernel-2.6.17-1.2139_FC5

Checking 'hlt' instruction... OK.
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
..MP-BIOS bug: 8254 timer not connected to IO-APIC
...trying to set up timer (IRQ0) through the 8259A ...  failed.
...trying to set up timer as Virtual Wire IRQ... works.
checking if image is initramfs... it is

upon looking at this wiki, you might wanna try

noapic nolapic

as kernel boot parameters
from: http://en.wikipedia.org/wiki/IO-APIC

I haven't tested if this extra nolapic helps any ... I will when I can

On many nvidia based chipsets the system will occasionally lock up on boot with
those messages unless you use "acpi_skip_timer_override=1".  It's worth a shot.

> noapic nolapic

Those are always a useful tool for debugging problems but I wouldn't use them in
production settings.

yeah, don't use nolapic ... the system clock goes mad if you do

Well, I've been looking at the kernel sources recently tring to see what goes
wrong. It looks like the error is generated within a function in
linux-2.6.1.x/arch/i386/kernel/io_apic.c called check_timer. The error only gets
printed if pin1 is anything but -1 and the function timer_irq_works returns zero
indicating that the timer IRQs are "defunct". There is a comment about this
function:

There is a nasty bug in some older SMP boards, their mptable lies
about the timer IRQ. We do the following to work around the situation:

- timer IRQ defaults to IO-APIC IRQ
- if this function detects that timer IRQs are defunct, then we fall
back to ISA timer IRQs

I think this shouldn't happen because I don't have an older SMP board ...

Well it looks like adding the boot flags 'noapic noioapic' is the easiest
option, you don't really need ioapic unless you run an smp kernel anyway, which
I don't so turning it off will have no effect (hopefully) ... I think it may
interfere with SELinux in some negative way, or maybe the events were unrelated.
The crash I had in the past while using the noapic flag may have been due to
SELinux not the noapic flag.

[This comment added as part of a mass-update to all open FC4 kernel bugs]

FC4 has now transitioned to the Fedora legacy project, which will continue to
release security related updates for the kernel.  As this bug is not security
related, it is unlikely to be fixed in an update for FC4, and has been migrated
to FC5.

Please retest with Fedora Core 5.

Thank you.

Created attachment 136895 [details]
dmesg output

This bug still happens on Fedora Core 5 kernel-2.6.17-1.2187_FC5.
Look at the attached dmesg output for details.

Another thing I noticed is that cpuinfo indicates 'stepping 9'
yet I only get 3 cpufrequency steps from 2.10 Ghz to 2.8 Ghz. This only started
happening after kernel-2.6.15-1.1833_FC4-i686 and also when these error messages
started showing up, and it continues through to FC5. It should be noted that I
tried opensuse 10.1 and it also happens .
 

A new kernel update has been released (Version: 2.6.18-1.2200.fc5)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

This bug has been placed in NEEDINFO state.
Due to the large volume of inactive bugs in bugzilla, if this bug is
still in this state in two weeks time, it will be closed.

Should this bug still be relevant after this period, the reporter
can reopen the bug at any time. Any other users on the Cc: list
of this bug can request that the bug be reopened by adding a
comment to the bug.

In the last few updates, some users upgrading from FC4->FC5
have reported that installing a kernel update has left their
systems unbootable. If you have been affected by this problem
please check you only have one version of device-mapper & lvm2
installed.  See bug 207474 for further details.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

If this bug has been fixed, but you are now experiencing a different
problem, please file a separate bug for the new problem.

Thank you.

This bug still happens in 2.6.18-1.2200.fc5
attaching the dmesg output.

Created attachment 138652 [details]
dmesg output

As the message suggests, these messages are indicative of a problem with the way
the BIOS has set up IRQ routing.  In the majority of cases, as also noted above,
 it doesn't seem to affect anything.   If this is actually causing problems, I
suggest filing a bug in the upstream kernel bugzilla at http://bugme.osdl.org
where upstream maintainers with APIC know how will be more likely to respond.