> Unfortunately, we are stuck with whatever Apple decided was right for the
> Mac hardware running MacOS, not UNIX. From the descriptions of the driver
> written here, it sounds like NetBSD is already playing a very old game
> called Pseudo-DMA: writing a minimal assembly language routine in locore.s
> to suck characters out of the UART chip FIFO and into a kernel ring buffer
> as quickly as we get receive interrupts, and then returning from the
> interrupt in minimum time, while posting some kind of software interrupt to
> call the normal tty handlers while the serial interrupts are not locked out
> (or calling the tty handler directly from the asm after interrupt level is
> set back to previous state prior to receive interrupt).

We are doing Pseudo-DMA with the post-a-software-interrupt respose.

> If we're still getting UART chip FIFO overflows with this kind of
> structure, then there are several possibilities for really fixing it:
> 
> 1. examine the interrupt handlers for all other higher priority devices
> with an eye toward reducing the amount of time they spend handling those
> interrupts (i.e. bum instructions out of 'em). Laborious, but rewarding
> when you're done.

The thing is that the serial ports are the highest-priority interrupt
at present! I recently checked my kernel source (which, admittedly, is
still at July 3's version), and nothing awas sitting at splhigh
for an extended period of time. :-( Though we wonder about the mrg
adb routines mucking stuff up.

> 2. directly calling the serial receive interrupt handler from other
> interrupt handlers (and other places that lock out interrupts for "a long
> time") in order to make sure that the UART FIFO does not overflow. Oh, did
> you say you wanted machine independent code? I'm terribly sorry...
> 
> It is my understanding that Apple plays a little bit of #2 so that the
> slower 68K Macs can keep up with LocalTalk.

AFAIK, Apple does a bit of #2 in reverse for LocalTalk. The reason
that the serial ports are the highest-priority is that LocalTalk reception
& transmition is too fast for interrupt servicing routines. Also, there
are sensitive response-time concerns with replying to packets. As LLAP
(LocalTalk Link Access Protocall) will shut down interrupts for a
significant amount of time, it's designed to peek at the modem port,
and keep other IO alive at the same time while dealing w/ LLAP.

> So, where do we start?

Good question. The first thing I can think of is to look for routines
which sit at splhigh, as you suggested. Though I think we're OK on that
one. The other possability is to snoop on the mrg routines. I know that
I can generate zs0b fifo overruns when nothing's on the printer port
merely by holding escape down for an extended time (>1 sec) while in
single-user mode w/ the netbsd11 kernel.

Weird, eh?

Take care,

Bill