Subject: Re: interrupt masking
To: None <bill@twwells.com, port-i386@netbsd.org>
From: Bruce Evans <bde@godzilla.zeta.org.au>
List: port-i386
Date: 09/19/1994 05:55:52
>In doing my fast interrupt code, I attempted to just re-enter the normal
>interrupt code, when the fast interrupt indicated that the slow code was to
>be executed.  That was a loser.

>That regular interrupt code masks and unmasks the interrupt, which means that
>the fast handler is locked out while the slow handler is executing, NOT the
>intended behavior!

One solution is to reenter on a different interrupt number.  The software
interrupt for ttys (SIR_TTY?) was designed for this purpose.  Skipping the
masking for the slow handlers behind fast handlers might work with no other
changes.  Using SIR_TTY is better because it has a more suitable (low)
priority.  The non-masking method might be better for new devices since it
is more generic (but how would multiple IRQs for the same class of devices
be handled? - it's convenient to have a single lower priority interrupt for
them all).

>On thinking about how to get around this, the question occured to me: why
>mask them at all? This is my understanding of what happens when an interrupt

1) EISA systems support (non-braindamaged) level sensitive interrupts.  If
these are used, then masking is required to stop interrupts being pending
all all the time.

2) The IRQ line may go up and down a few times while an interrupt is being
serviced.  If the interrupt isn't masked, then there will be an extra h/w
interrupt to look at for each rising edge and an extra pending bit to
handle after the first interrupt is serviced.  It's not clear whether the
overhead for this (large overhead a few times) is smaller than the overhead
for masking (small overhead many times).

>In fact, the mask only has the effect of preventing recursive interrupts
>during the handler call itself, as other recursive interrupts are dealt with
>by other means. And, at that, it isn't entirely effective.

>Consider an interrupt just after the unmask and before the cpl is restored.
>That will cause a pending bit to be set, which will cause doreti to go to the
>resume point and then execute the handler with the interrupts unmasked.

The new interrupt will set the mask as well as the pending bit so there is
no problem.

Bruce