Subject: Re: new serial driver
To: None <jonb@metronet.com, port-pc532@NetBSD.ORG>
From: Phil Budne <budd@cs.bu.edu>
List: port-pc532
Date: 11/23/1996 23:28:01
	There are 2 things to note from this.  First, pppd saw the modem
	hang up.  It never used to, and I passed some LCP parameters to
	pppd to give up when the connection had gone.  I like pppd getting
	SIGHUP much better.  This part is looking real good.

I implemented CD following, glad THAT'S working for you!

	Second, I have those fifo overruns.  Never had them before but
	then I don't think the old driver used the interrupts/fifos.
	At least the kernel never reported allocating interrupts for
	them. On the other hand, how could you reliably get data at
	38400 without interrupts?  Is there some way to avoid the
	overruns?  I run the 14.4 modem on tty02 at 38400 if that
	makes any difference...


The original driver didn't try to do flow control, and didn't report
failures.  Some detail;


I copied some clever code from Chris Torek's 4.4BSD SPARC port where
data is copied out of the SCN FIFO's at interrupt level into a ring
buffer that's emptied from a lower priority (soft) interrupt in a way
that requires a minimum of interrupt masking.  Two new kernel printf()
are possible; "FIFO overrun" (the chip receieved a fourth character
while all three FIFO positions were full), and "ring buffer overrun"
if the ring buffer has filled up.  I use the special RXRDY interrupt
line that George and Dave architected so that RXRDY interrupts are
NEVER masked (and herein lies a problem).

Ian Dall just sent me mail noting that once the ring buffer (or higher
level structures in the line discipline) fill that information isn't
passed down to the interrupt service routine to STOP removing
characters from the FIFO, and force the chip's hardware flow control
to turn off CTS.  Ian said he wouldn't have the time to do anything
immediately, and neither do I, so backing down to a 1.2-release kernel
should fix you up for now!

-phil