Subject: Re: interrupt masking
To: None <port-i386@netbsd.org>
From: T. William Wells <bill@twwells.com>
List: port-i386
Date: 09/18/1994 22:24:42
In article <9409181955.AA16995@godzilla.zeta.org.au>,
Bruce Evans <bde@godzilla.zeta.org.au> wrote:
: >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.

"Designed"? I hope not! "Intended", perhaps, but, unless I've missed
something, essentially none of the code has been written.

:           Using SIR_TTY is better because it has a more suitable (low)
: priority.

That will not work. The slow handler has to be at least spltty.

: >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.

Masking? One would suppose that interrupt acknowledgement would be more
appropriate under the circumstances.

: 2) The IRQ line may go up and down a few times while an interrupt is being
: serviced.

One hopes not, unless they represent real interrupts.

:            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).

Probably the latter. And one suppose that the drivers for devices where this
occurs, the driver could, and should, minimize the problem.

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

Urk. So it will.