> On Wed, 30 Jul 1997, Colin Wood wrote:
> 
> > Is there any kind of adverse interaction between spltty() and splzs() that
> > might be causing the problem?  Or is spltty only used by the console ite
> > stuff and not by a pty?
> 
> And in the `answer the question, bucko' department:
> 
> I'm not aware of any interactions between the spltty() and splserial()
> (nee splzs()) calls.

Nor am I. :-)

> spltty() is used by the tty subsystem in general, but does not affect the
> higher-priority interrupts that splserial() blocks.

spltty is to block interrupts which will change the queues assosciated
with the tty's (kept in clists now). Originally (back when 1200 baud
was FAST, and people actually dialed in at 110 baud) spltty would block
the interrupts from the serial cards. Or, if the card had DMA, it would
block DMA-done interrupts.

Well, to support faster transfer from serial ports w/o much buffering,
the idea of silos came about (I'm paraphrasing & embelishing what I
read in both the 4.3 and 4.4 BSD books). So a fast little interrupt
routine gets characters from the serial port and throws them in the
silo. Then later, when no one else's touching the tty queues, the silo
gets drained into the tty system. So spltty only had to block the
draining of the silo, not the reading from the chip.

On mac68k, we use the silo approach. We impliment the silo as a ring
buffer, and report errors as "ring overflows".

I doubt the change to the zstty driver recently will cause more fifo
overruns. fifo overruns happen when that fast little fill-the-silo
routine can't run. Scott's change lowered the interrupt level, so we
now are accepting interrupts for more time.

I wouldn't doubt the splraise changes might have broken something, but
if so, the problem is that other parts of the code assume that you can
use spltty to get rid of splhigh (or splserial or whatever).

Take care,

Bill