Spurious Interrupt
 

Hello all,

I have a CentOS 4.3 server running on a Supermicro PDSMi motherboard. Seemingly out of nowhere, I received the following in the Dmesg:

spurious 8259A interrupt: IRQ7

This did not happen during boot, but after. I don't recall running, or doing anything during the time. Does anyone know what this cryptic message means, if it is serious, and how to make it go away?

Thanks,
Tom

just read this description. Some guy made a website and he calls it spuriousinterrupt cause he thinks the name is neat, but he gives the description flat out on that above page.

Thanks for the information. Sort of bizarre that someone named a site of this error message. One thing I had done prior to the interrupt was to blacklist the pciehp driver (PCI Hotplug) to prevent it from loading during boot due to some errors. I wonder if the server was trying to access that and couldn't because the software driver had been unloaded. Who knows...

I'll keep an eye on it and post more to this forum if I find additional information.

Best Regards,
Tom

I've started noticing this error on 2.6.16 and up kernels too; I seem to be getting it for my parrallel port tho.

Well, for a quick update, I had an idea. I read that this can occur on motherboards with APIC that are running with a uniprocessor kernel. The PDSMi Supermicro motherboard can run Pentium Dual Core chips which will run with an SMP kernel as they are two logical processors. However, this particular server is running a Celeron D 3.06GHz processor which, despite the misleading D, only has 1 logical processor and is not dual core.

I noticed on Wikipedia: http://en.wikipedia.org/wiki/Intel_APIC_Architecture that this sort of configuration can cause the interrupts to occur. So I set the noapic and nolapic flags in grub.conf and rebooted. It looks like the interrupt is back this morning though. Only one, as always and apparently several hours after the last boot. Bizarre. I'm running the latest kernel for CentOS 4.3: 2.6.9-34.0.2.EL so am hoping it is just some bug that will get resolved and not indicative of an actual hardware problem.

Let me know if you make any headway on this, and I'll do the same.

Best Regards,
Tom

A second quick update. It does not appear to have any relation to the ,previously mentioned, hotplug error. The spurious interrupt continued after removing that from the blacklist and rebooting.

This is really strange. The interrupt occurs once, typically several hours after the last boot. Anyway, I will keep looking. If anyone else sees this with the same kernel, please post.

I get it on an AMD processor motherboard.

Okay, so we know it is not only Intel based. The trouble with a 'spurious' error is that we have no idea where to start looking. Anyway, adding noapic and nolapic to the boot line had no impact, I received the spurious interrupt several hours after boot.

I still think that this has something to do with running a uniprocessor kernel on a board that can handle Pentium D chips. I think the PDSMi board from Supermicro uses APIC and that is what creates these interrupts. Note, I do have a support line opened with Supermicro but haven't made much headway.

Last night I installed an SMP kernel on the machine (even though it only has 1 processor) and rebooted with that kernel. As of this morning, there is no spurious interrupt. So, maybe that is what is going on. Time will tell. I'll wait another day or so, then boot back with a uniprocessor kernel and let all know.

I will be on vacation, up in the moutains for the rest of the week. It is doubtful (and probably a good thing) that I'll have much internet access... but I'll post the state of the server when I get back.

Best Regards,
Tom

I really need to go on vacation :-).

Anyway, I have defeated the spurious interrupt. I actually went ahead and loaded an SMP kernel on the system, waited a day and no interrupt. In addition, I am now seeing proper APIC entries in dmesg:

[ter@neon ~]$ dmesg | grep -i apic
Using APIC driver default
ACPI: MADT (v001 PTLTD APIC 0x06040000 LTP 0x00000000) @ 0x7fee9f0f
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
Enabling APIC mode: Flat. Using 0 I/O APICs
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
ACPI: IOAPIC (id[0x02] address[0xfec10000] gsi_base[24])
IOAPIC[1]: apic_id 2, version 32, address 0xfec10000, GSI 24-47
ENABLING IO-APIC IRQs
ACPI: Using IOAPIC for interrupt routing

So now the only silly thing is that I have to run an SMP kernel on a motherboard with a Celeron D processor in order to get APIC running okay. Seems mostly harmless though. I should have forked over the extra 50 bucks and bought a Pentium D! Ah well, live and learn.

Anyway thanks for all of the help and suggestions with this issue. I have sent an email to SuperMicro tech support regarding incompatibilities with APIC on their MB and uniprocessor linux kernels so, hopefully, they'll take action and fix it. Other than that, am running SMP fine and will just leave it like that.

Best Regards,
Tom