spurious interrupt 8259A

[Anthony_141]

We have ML350 G4's we are loading with Redhat Advanced Server 2.1 (note we've had this configuration on ML350 G4p's for years, but we were unable to get G4p's anymore so ended up with a few G4's).

Our kernel is:

2.4.9-e.62 #1 Fri Apr 8 19:02:11 EDT 2005 i686 unknown

Everything seems to be running fine, except once in awhile (maybe every few days) we get the following message:

spurious 8259A interrupt: IRQ7

Our /proc/interrupt shows this for IRQ7:

7: 568515 XT-PIC ioc0, ioc1

Googling shows this error is fairly common, but real answers on what it is and what to do about are not common.

Note we've loaded SUSE Enterprise 10 (a much newer Linux) on two of the G4's and don't have the same messages show up, but for our environment we must use this Redhat 2.1 on these G4's.

If anyone has some real answers on what this means and what, if anything, we should do about it, we would appreciate it.

[Matti_Kurkela · Accepted solution]

Basically, it means: the CPU got an interrupt signal, so the kernel checked all the hardware devices that are known as capable of sending IRQ7 interrupt signals... but no device needed attention after all.

When a device sends any IRQ signal, the interrupt controller receives it first. It sends first a generic interrupt signal to the CPU, and the CPU acknowledges it. The next step would be that the CPU reads the IRQ number from the interrupt controller.

If the interrupt signal from the device vanishes after the CPU has acknowledged the interrupt but before the IRQ number has been reported to the CPU, the interrupt controller must report *some* IRQ number anyway. According to the hardware documentation, the interrupt controller reports IRQ 7 at that point.

See this FAQ:
http://www.linuxfromscratch.org/lfs/faq.html#spurious-8259A-interrupt
It refers to a Google Groups thread in linux.kernel, which mentions (apparently from old Intel 8259 chip documentation):
-------------------------
* A spurious IRQ7 occurs, in the 8259, if any interrupt request duration is too short or hasn't met the setup time required by the 8259A.

* This is a standard 8259 behavior under specific conditions. IRQ7
is triggered
- when IRQ7 is enabled and is requested
OR
- when an interrupt request clears (by itself) before the CPU services the request.

A software solution would be to write an IRQ7
handler that checks the various possible requesters and to handle any "missed" interrupts from any of those requesters.
-------------------------

In the Google Groups thread, there is a long technical discussion about this.

The consensus seems to be: if it happens rarely, it is not a problem.

Unless you can modify the hardware, there is not much you can do for an actual fix.

MK

[Anthony_141]

Thank you for the information.