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:47:07
In article <199409182006.QAA26335@duality.gnu.ai.mit.edu>,
Charles M. Hannum <mycroft@gnu.ai.mit.edu> wrote:
:    However, the cpl&ipending test
:    does the same thing.
:
: No, it doesn't.  If the interrupt were simply recorded in ipending,
: then you could get excessive extra interrupts due to race conditions.
: (e.g.  Ethernet driver reads last packet.  Before it's done processing
: it, another one arrives, which triggers an interrupt.  It gets back to
: the top of its loop and notices a new packet, and reads it.  There's
: no need for another interrupt.)

I just decided to live with that in the serial driver. Because it eats
everything and doesn't return until the UARTs are quiescent, the odds of an
extra interrupt are tiny. One would hope that other drivers are written
similarly. (OTOH, this implies extra time spent in each driver, making sure
that everything is taken care of. OTTH, I decided that, given the losing
nature of interrupts on the '86, I had *better* do it that way....)

: no need for another interrupt.)  One could even envision a rogue
: device causing an infinite loop.

That doesn't make sense. In such a case, no matter what you do, the machine
is going to interrupt itself to death anyway.

: Whether or not this is a performance penalty in practice is another
: question.

I doubt it.

:    (Actually, if I'm reading the code right, the ipending
:    bits aren't ever set because of an interrupt on the same channel;
:
: This is true iff the interrupt is masked in the ICU.

That's what I meant.

:    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.
:
: Hm.  That sounds plausible.  If so, the unmasking should be done in
: doreti on the final exit, it seems.  This would also prevent
: starvation.

As was pointed out, the mask is set by the interrupt, so this isn't a problem.

: I could be convinced to switch the way this is done, except that I
: don't agree with the way you're doing the fast interrupt handling.

The two issues are separate. The masking question is one of efficiency. As
for my own problem, since fast interrupts are handled with interrupts
disabled, masking is an irrelevancy. My concern is just this: if masking
isn't necessary, I can just remove the mask/unmask from the interrupt code
and re-use the slow interrupt handler code. Otherwise, I have to duplicate
that code, minus some irrelevancies (like masking), and then hack a few other
things (like changing the resume address when a fast handler is installed).

: The XintrN routines are specifically for dealing with hardware
: interrupts; software interrupts should go through a different
: mechanism.

Well, I looked for such a mechanism. What I found barely qualifies as a
kluge, much less a mechanism. I'm not about to rewrite the interrupt handling;
I have enough on my plate as it is. I chose my mechanism, not because it was
the best (it isn't), but because it was the fastest route to a serial driver
that doesn't lose characters like a sieve.

When y'all actually implement something, I'll modify my driver to use it. In
the mean time, I'm just going to get this done as quickly as possible.