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 ([EMAIL PROTECTED] / [EMAIL PROTECTED]) running linux -- Jean-Paul Vincent [EMAIL PROTECTED]
