> 
> Hi all, I may have just gotten some insite to the serial problems with 1.1 on the
> mac.  I was talking with a co-worker and he mentioned that the Sun serial driver
> handled handshaking badly.  Actually it handled
> transmit handshaking fine, but payed no attention
> to receive handshaking.  Specifically, it never dropped RS causing lots
> of fifo overflows, just like we've been seeing on NetBSD.  I dont know
> exaclty how much the current serial driver is based on the Sun3 SunOS3.5 driver,
> but the error messages zs0a seem to say it is, at least in some part.
> 
> One way to see is for ppl to payattention
> and see if fifo errors occur
> during large file "puts"
> and "gets".  If they only occur during "gets" we probablly have our
> culprit.  Another way would be for someone eith a modem with RS/CS lights
> to wathch both, if the CS changes on/off but the RS never drops then
> that for sure is our problem.
> 
> Like I said, I dont know if this for sure is the problem, but it may be
> something to look into espically if the serial driver is based
> on the sun serial driver, and if that is based of SunOS3.x/4.1.<4 serial
> code.

I don't know how closely our driver follows the SunOS driver, but
our driver is a hacked version of the NetBSD/Sun & NetBSD/SPARC driver.

Using handshaking would be nice, but we can't for 2 reasons:

1) Apple, in its wisdom, did not give us two outgoing control lines.
So we can either have CTS, or we can have DTR. DTR is usually
configured to hang up the modem, so we don't have an extra line for
handshaking with a modem. (The chip's CTS line turns output line
drivers on and off)

2) Most of the errors we have are fifo overflows, not ring overflows.
Handshaking would make a lot of sence if the ring were the problem.
I.E. if the driver saw the computer was getting behind (the ring was
filling), and then asked for the sender to slow down. The other
solution to this latter problem is to just make the ring bigger
(something the very latest version of the code does; zsvar.h.951110).

The problem is that we're getting fifo errors. We aren't getting to
the chip quickly enough to not loose data. So we can't change a handshake
line in time to save data (if we could change the line, we could just get
the data). Also, the hardware won't help us either. There's no magic
mode we can turn on. :-(

The problem is that something is keeping interrupts off for an extended
period of time. :-(

Take care,

Bill