Re: spurious IRQ interrupt 8259..

[Jean-Paul Vincent <jpvincent1@wanadoo.fr>]

 Bonjour,

Plus de précisions, peut-être :

> I believe the problem with IRQ 7 has a solution.
> 
> First, the problem. The data sheet for the interrupt controller chip used
> in the original PC (Intel 8259, if I remember the part number correctly)
> includes a somewhat obscure description of what happens when there is a
> glitch on an interrupt request line. If the request into the 8259 is
> negated before the processor has recognized the resulting interrupt request
> output from the 8259, the 8259 can simply negate that output and no interrupt
> occurs. But what if the processor has recognized the interrupt request and
> begins an interrupt acknowledge cycle after the input to the 8259 has gone
> away? The 8259 has to supply a vector to the processor to complete the
> interrupt acknowledge cycle. It uses vector 7, but *does not set the
> corresponding bit in the In Service Register of the 8259*. Note that this
> spurious interrupt 7 can occur even if this interrupt is already active
> from a real IRQ 7.
> 
> The solution: the interrupt handler for IRQ7 (and IRQ15 on a PC/AT) should
> check the bit in the In Service Register of the 8259, and do an immediate
> IRET if it is not set (indicating a spurious interrupt from a glitch). It
> must also check and set a flag if a valid IRQ7 is processed (do this before
> STI to prevent race conditions!); if the flag is already set, it means that
> this is a spurious IRQ7 occurring during the processing of a valid one, and
> again an immediate IRET is called for.
> 
> This discussion is all theoretical, based on the data sheet, although I
> plan to implement this in a project at work soon (unfortunately, not
> involving VSTa).
> -- 
> Bill Roman (songdog!roman@eskimo.com / roman@songdog.uucp) running linux

-- 
Jean-Paul Vincent
jpvincent1@wanadoo.fr