Simpler Navigation coming for Servers and Operating Systems
Coming soon: a much simpler Servers and Operating Systems section of the Community. We will combine many of the older boards, and you won't have to click through so many levels to get at the information you need. If you are looking for an older board and do not find it, check the consolidated boards, as the posts are still there.
cancel
Showing results for 
Search instead for 
Did you mean: 

spurious interrupt 8259A

SOLVED
Go to solution
Anthony_141
Regular Advisor

spurious interrupt 8259A

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.

2 REPLIES
Matti_Kurkela
Honored Contributor
Solution

Re: spurious interrupt 8259A

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
MK
Anthony_141
Regular Advisor

Re: spurious interrupt 8259A

Thank you for the information.