Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm dealing with some really old point-of-sale machines that run a point-of-sale flavour of SuSE 9. It turns out that its kernel is affected by an old bug that makes USB 2.0 functionality unstable (hotplugging of devices may result in "control timeout on ep0out" messages in /var/log/messages, and the hotplugged device becomes unusable). I first tried to work around it by unloading the ehci-hcd module, so that the USB 2.0 devices just fallback to USB 1.1. But now I discover that an HP laser printer connected to the POS machine prints extremely slowly in USB 1.1 mode.

Some more search on Google suggests that the alternative solution is to put the noapic option in /boot/grub/menu.lst.

But what kind of bad things can I expect to happen if I disable APIC, besides performance degradation? I hear that ACPI is closely related to APIC, but I'm not concerned about ACPI because we explicitly turn it off in GRUB anyway. In theory, would some devices simply not work when APIC is disabled?

More information:

  • single CPU, single core system (some Celeron 2.5 GHz)
  • kernel 2.6.5-something-something
share|improve this question
I don't think that APIC is "closely related to" ACPI. APIC is (it seems, looking at wikipedia) exclusive to x86 motherboards with specific Intel chipsets (using a Celeron is not a guarantee of that); if you don't have one, then turning kernel support for it off shouldn't do any harm. – goldilocks Dec 11 '12 at 14:47

Well, first, I wonder if you could just substitute in a newer kernel? Or if you can find the patches that fix the bug, you could possibly apply them to the 2.6.5 kernel.

Other than that, the APIC is used for interrupt routing. If you turn it off, the kernel should fall back to the older PIC method. The result should be more devices sharing interrupts (as you'll have far fewer), and a slight slowdown. Probably not important.

What'd break would be that maybe you'd lose interrupts entirely (in which case, it'll surely not boot), or you'll lose them from some device (it'll probably be very obvious, the device probably won't even initialize). You'll lose one of the time-keeping methods on the system, which is probably the most subtle thing—the system clock may drift, or drift differently than it did before.

If noapic doesn't work, you could also try nolapic or adding a PCI USB 2.0 controller, assuming the hardware allows it.

share|improve this answer
Using a newer kernel is not an option because the original one was customized by IBM or SuSE, and nobody among the stakeholders has the expertise to guarantee that patching on our own will work. What is it about the PCI USB 2.0 controller solution? Does it not rely on APIC somehow? – Kal Dec 12 '12 at 2:05
@Kal Well, it relies on APIC (almost all interrupts do, when its enabled)—but clearly APIC isn't completely broken on your board, else it wouldn't boot at all. But it'll be a different chipset, one that hopefully isn't bitten by whatever bug is taking out the onboard USB2 controller. You can also try various PCI slots, often that'll get different interrupt routing. For around $10, seems worth a shot to me. – derobert Dec 12 '12 at 16:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.