spurious interrupt?

[Tom Mitchell]

On Fri, Mar 26, 2004 at 09:46:42AM -0700, Michal Jaegermann wrote:
> On Thu, Mar 25, 2004 at 09:35:45PM -0700, donald raikes wrote:
> > 
> > While waiting for the dependencies to be resolved, I get the following message displayed:
> > 
> > spurious 8259A interrupt: IRQ7
> > 
> > Any idea what may be causing this?
> 
> See, for example, here:
> 
> http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=3C174EDD.9090306%40hotmail.com&rnum=2&prev=/groups%3Fq%3Dspurious%2B8259A%2Binterrupt%253A%2BIRQ7%26meta%3Dsite%253Dgroups
> 
> and other messages in that thread.  Usually this is a hardware
> problem, and if sporadic then nothing to worrry about, but see that
> URL.
> 
> If you will search in "google groups" then you will find much more. :-)

A spurious interrupt is commonly seen when interrupt service code
checks a device and there is nothing to service.

Is your BIOS setup to deal with things like automatic power management
or something.  How are interrupts assigned.  Are there multiple
devices vectored to the same interrupt....  Multiple video resources,
multiple PCI cards, multiple PCI buses, multiple processors.

If you get a spurious interrupt once in a while but in all other
regards things are fine, then things are fine.

There could be a small time window race in the interrupt handler where
one device and it's interrupt is not correctly masked or cleared.
Or, what happens when a dynamic driver is loaded and unloaded....

You could also have some unused device that has an active watchdog
timer set on by power on default.  It interrupts but the device is not
being checked by software i.e.  it's interrupt is vectored to a
different device handler.

To sort it all out you have to inventory all hardware.  Then map all
hardware interrupts through the hardware to handlers.  The occasional
spurious interrupt is a non problem.  A lost/ dropped interrupt can
be.   

So, if things are working fine do not fret.

Of interest one early (1979) hardware application note with a
reference design for an interrupt controller had a design issue.  It
could produce occasional spurious interrupts in some systems.  If I
recall it was a Motorola application note but it could have been
Intel.  It had a ~2 ns instability window or some such thing as
interrupts were masked and latched.  Now with fast logic and modern
integration levels this same design would have a sub pico second
window.  This classic design might still be used inside complex parts
with multiple functional blocks.  The good news is that it does not
discard an interrupt.

And yes it could also be hardware, a cold solder joint, a cracked pull
up or termination resistor or cap....

Again, if things are working fine do not fret.

-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.