Re: spurious 8259A interrupt

[Jamie Lokier <jamie@shareable.org>]

Richard B. Johnson wrote:
> > For those rare occasions when an interrupt handler wants to
> > re-enable interrupts (sti), _then_ it could mask the interrupt
> > that called the handler.
>
> It would work. However, the driver would then have to "know"
> if the interrupt came from IO-APIC or from the 8259. It also
> would have to "know" what IRQ it was actually using, etc.,

The generic interrupt handlers in Linux _do_ know all that.  They
need to, to mask the interrupt :)

The driver would not need to know: a global per-cpu variable can keep
track of where the most recent interrupt came from.

> So, all the dirty details were put in the kernel code so that the
> ISR only needs to know it was called as a result of an interrupt.

Yes, but that doesn't explain the masking.  It explains why there are
generic interrupt handlers (which know about the 8259, various APIC
etc.) and the driver interrupt handlers.

> There is no problem with masking ON/OFF the interrupt
> input to the 8259, In fact, this can be used to generate
> another (unreliable) edge if the IRQ line is still asserted.

No, there is no problem.  But there is a performance impact.  Masking
and unmasking the 8259 is an I/O operation which may be quite slow.

If we don't need it, why do we take the performance hit?

> The IRQ7 spurious is usually an artifact of a crappy motherboard
> design [+ good explanation].

Thanks.  That was very informative.

-- Jamie