Re: IRQ handling

Andrew Valencia writes:

> If you write a parallel-port driver, and you depend on interrupts, be
> prepared to be fielding endless complaints about "it's sluggish" or
> "sometimes it stops sending for a couple seconds" and such.

I believe you, but isn't "a couple seconds" a rather large timeout value?

> As for the fast iret stub for IRQ7, I'll be happy to enhance the ISR
> registry code so the stub gets removed when a handler gets registered. But
> it would be a big mistake to base the printer driver on interrupts--the
> latest 386BSD printer driver was done by me and a German guy, after we found
> out how many people couldn't use the interrupt-based one.

Ok, my interest in this wasn't printers, so I don't care. I just don't see
sparse events, as plip frames, implemented though busy looping.

I got this from Bill Roman, but I haven't verified it yet.

songdog!roman@eskinews.eskimo.com writes:
> 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

Kind regards,
/Tommy
Received on Wed Mar 16 08:44:36 1994