On Tue, 11 Aug 1998, Colin Wood wrote:

> One thing that was mentioned was having all of the upper-level interrupt
> handlers check for the presence of lower-priority interrupts just after
> finishing their processing and before returning.  If a clock interrupt was
> pending, the higher-priority handler could call the clock interrupt
> handler and then return after the clock interrupt handler had returned (if
> that's not too confusing ;-)  I think this is more or less how it was
> explained the last time this issue came up.

That's one solution. And we might have to go to it. But it makes for gross
kluges. All of the problems folks have had w/ kernels panicing in zsc0
attach are because we are calling zshard, the serial port interupt
servicer, from the adb code. So each time someone's had a failure, it was
because an ADB interupt came in, not because of what the serial chip did!

> I suppose another way to do it (if this is not already done), and perhaps
> the way that i386 does it, is to have the hardware interrupt handlers
> perform the absolute minimum necessary to service the interrupt and then
> schedule a software interrupt at some point in the future to finish off
> processing (of course, we could already be doing this, I haven't looked
> too deeply into how our interrupt handling occurs).  Likewise, I don't
> know what the effects of this are on performance.  I also am not entirely
> sure what kind of locking might be necessary in order to prevent
> corruption of certain data structures when the hardware interrupt handler
> is called while the software interrupt handler is currently running....oh
> well.

I need to learn more about how i386 does it.

How the serial port does it, and how other things might need to start
doing, is that interupt servicing happens in two steps. One step talks to
the chip, and either sends or receives bytes (in zshard()). The second
part passes received bytes off to the tty system, or asks it for more. The
second part, zssoft(), is only run when the tty system can service the
requests (when spltty is not asserted).

I'm not sure how we could do this for ethernet drivers and scsi devices...

Take care,

Bill