MP-BIOS BUG 8254 timer not connected - use noapic option to boot
Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
MP-BIOS BUG 8254 timer not connected - use noapic option to boot
I believe many of you have come across the same problem. Maybe most of you used some Ubuntu version. What I am talking about is the "MP-BIOS bug: 8254 timer not connected" message that one would get when booting a live CD with a Linux distro.
The workaround is to use noapic option when booting. Use the F6 key (for some distros this can be F4 I believe) to change to boot command line and add noapic. This would get you going.
This is as much info as a newbie would need to overcome this problem. If you are a geek and you want to know more about this read on.
The story behind the message is as follows. The kernel tries to find the timer that syncs the IO devices and fails. The reason is that with the latest hardware (motherboards) have moved the timer to a different place. The problem is that the kernel is not yet up-to-date with this change (although the kernel developers are) and fails during the check. If you are curious to see the details you can download the latest kernel's source and check the function check_timer(void) in io_apic.c file. The comments to the function say
FIXME: really need to revamp this for modern platforms only.
This is if you check the source for x86_64 configuration.
I searched on Google for what APIC is and found this in Wikipedia
There is even a link to the Intel's docs dedicated to APIC.
So, I know what the problem is and there is a workaround for it. But what bothers me is:
1. Do we need APIC?
I am guessing we do, because it is a new way of syncing with IO devices (and not only IO?!?), which means that with APIC my video will be faster and than I can truely enjoy my 3D desktop.
2. Why the kernel guys haven't fixed it yet?
Is it something complicated? I hope not and I hope that reading Intel's docs would help here. No free time? Well, Linux is for the community, but from the community too. If no one else has the time to do it I can make the changes in the code. Can some one explain how to set up a kernel development environment?
Because this is a major change in the kernel the more people test it the better. So jump in. Only some one please explain how to test the new kernel. Is compiling and using it the only way? I am guessing I should be able to call the function from my dev environment?!?
Actually I have this very issue using Mandriva 2008 as well as Ubuntu Gutsy Gibbon RC... Only tried the LiveCDs of these. Irqs me to no end! ;-)
But my 64Studio installation doesn't seem affected by it, which seems odd to me as it uses kernel 2.6.21-something (can't remember exactly). Admittedly, this is a real-time, multimedia kernel so they may have done some changes to the kernel which somehow sorts this out. Note that 64studio is installed on my PC and not just run as a live distro!
PC Specs are as follows:
AMD AM2 5200+
4 Gig RAM
Gigabyte M55S-S3 (rev 1.1) with latest BIOS
Nvidia 7300 GS
But I would like to see the bug fixed in Ubuntu (without having to use the noapic boot option as this plays havoc with USB ports) as I'd like to use it as my general desktop.
Actually, I found a site that describes the very origin of the problem. It turns out that the BIOS is made M$ only and nothing else would run, unless a hack is applied. Check this site out:
I am guessing that many people lean... bend over for M$ like (in my case) ASUS et al.
In my case I had troubles with the very hot Ubunut 7.10. It didn't recognise my HDs and the network card didn't work. I had to go back a few versions of my BIOS in order to make things work.
So far my advice is - don't buy a motherboard which says MS compatible. It is a sign that it is ONLY MS compatible and most likely it won't let any thing else run on it.
Crazy stuff this getting into bed with the M$ devil. I've had a brief read of that url you supplied and was interesting. I don't run gentoo, which doesn't mean the instructions/details there don't apply but good to know if I need to check/fix something! Thanks for that...
I got the same problem after installing 32bit Fedora 8. What is interesting, however, is that problem occurred on second installation time. The first time I installed Fedora 8 there were no problems. Seems pretty random. It's strange that no-one really seems to know the answer to this problem. Reading some nVidia info prompted to use 'acpi_skip_timer_override' kernel parameter on boot instead of 'noapic', but I haven't tested that yet.
Funny thing that it seems to affect both Intels and AMD's processors if they are dual-core. I haven't read about a case of this problem with single-core processors.
I used to have this same issue in FC5 and FC6 (but not FC4). I switched to Slackware and the problem has disappeared. Maybe it's just a new kernel ... or maybe it just isn't patched to hell by the Red Hat crew ?
As far as I am concerned, I had to make up my mind to change the motherboard: the crashes frequency was increasing (several a day). I think I was having a faulty motherboard. My problem was most probably not due to the ACPI message. The article on Gentoo wiki is very instructive. I discovered that my BIOS DSDT table was compiled with M$ compiler not Intel (my new motherboard also, I wonder which BIOS does not use M$ compiler...).
By the way it's now hard to find AMD 939 socket boards. I found a Foxconn 6150K8MD (Winfast) which seems to be OK. I'll post later my feedback on the HCL.
Hmmm, I tried a 84bit Slackware based live CD (BlueWhite64) and it didn't bring up the error. I then tried Ubuntu's latest (8.04 Alpha1) and it still came up with the issue.
But tnen I found a post in Ubuntu bug tracker where the user described turning off the Hyper Threading (HPET Support option on my BIOS) and it worked! I coudl boot the Ubuntu CD without an issue.
In email discussions I had with the guy who posted the details of the BIOS fix he also said a BIOS update should also fix it but I have the latest for my mobo so not sure about whether it's a bad BIOS from mobo manufacturer (in the sense that it's not coded to spec) as most posts I've read have stated it's not the linux kernel which is at fault.
Anyway, with the tweak to my BIOS I can happily run distros I couldn't before (without changing my mobo).
I can boot my Toshiba laptop (A105-S101, Intel Celeron M - 1.6 GHz, 512 MB RAM)with the Ubuntu 7.10 live cd ok, without having to add the noapic option.But when I installed it on my c:drive - I tried linux alone and then win-xp/linux dualboot configurations,nothing happens (I just get a blank screen) after I select Ubuntu linux from the grub menu - even after editing the grub boot line and adding the noapic option.
Try a different version of the distro, you may strike lucky!
hello, I tried to install ubuntu 8.10 on 2 computers with success on the first, but came up with the 8254 bug on the second (an emachines 170). As a newcomer to linux I had trouble trying to use the tips given here. Therefore I tried using an earlier version, ubuntu 8.04 (hardy heron) on a DVD supplied with Linux for dummies,all in one desk reference; this time with complete success and easier than installing on the first computer.
This problem can't be that new as I get the same error with Ubuntu 8.10 and Debian 5.01 when trying to install on a IBM server (x-series 232) from 2002! I also get it on my Laptop every time it boots, any idea on how to fix it on an already installed system (debian 5.01)?
This issue has certainly bitten me recently on a custom built kernel built using a X86_64 box for a X86_32 ATOM architecture.
I was using OpenEmbedded to build the original kernel and it worked fine on a ATOM Z510. I wanted to test some kernel modules, so I got the same source code as the OE and hand built the kernel using the native build tools (x86_64) and GCC expecting it to work since it was a X86 platform. WRONG. I kept getting kernel panics with the hand built kernel with error:
"[ 0.003981] Enabling APIC mode: Flat. Using 1 I/O APICs
[ 0.003981] ..TIMER: vector=0x30 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 0.003981] ..MP-BIOS bug: 8254 timer not connected to IO-APIC
[ 0.004000] ...trying to set up timer (IRQ0) through the 8259A ...
[ 0.004000] ..... (found apic 0 pin 2) ...
[ 0.004000] ....... failed.
[ 0.004000] ...trying to set up timer as Virtual Wire IRQ...
[ 0.004000] ..... failed.
[ 0.004000] ...trying to set up timer as ExtINT IRQ...
[ 0.004000] ..... failed .
[ 0.004000] Kernel panic - not syncing: IO-APIC + timer doesn't work! Boot with apic=debug and send a report. Then try booting with the 'noapic' option.
Trolled every mailing list thread I could think of trying to find a solution, but no luck. None of the ACPI or APIC turning off's worked.
Then I built it using the OE built GCC which was targetted at "pentiumpro" CPU type (eg: gcc -mtune=pentiumpro).
Vola. It works.
So if anyone out there is experiencing a similar problem with a custom built kernel, this may be the cause. Hope it helps.