Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 beta 3/9/83; site dual.UUCP
Path: utzoo!linus!security!genrad!grkermit!mit-vax!eagle!mhuxl!ihnp4!zehntel!dual!fair
From: fair@dual.UUCP (Erik E. Fair)
Newsgroups: net.unix-wizards,net.bugs.usg,net.bugs.v7
Subject: Serial driver problem query (v7 vs. System III/V)
Message-ID: <239@dual.UUCP>
Date: Fri, 27-Jan-84 21:49:24 EST
Article-I.D.: dual.239
Posted: Fri Jan 27 21:49:24 1984
Date-Received: Sun, 29-Jan-84 00:50:58 EST
Organization: Dual Systems, Berkeley, CA
Lines: 54

We're having troubles with our serial driver & System III.

The DUAL SIO4/DMA looks somewhat like a DEC DH-11, in that it is DMA on
output, and has a 256 byte FIFO for input (shared between the four
ports on the board).

The problem manifested itself as a 1200 baud port with a modem on it
would lock up randomly and refuse to function until the next time the
system was reset. This only happened on our systems which were running
System III UNIX. Version 7 did, and continues to, work just fine.

After much digging through the tty driver, and lots of hand waving, I
found that the serial driver was not waiting for the USARTs to get
themselves into an idle or ready state before setting the baud rate &
character width, and other things of import.

It seems that where Version 7 always did either an output flush or a
wait-until-output-has-drained before even asking the serial driver to
perform functions like that, System III just goes ahead & does it. Thus
does the USART get poked with information when it's busy outputting a
character, and it gets upset and refuses to deal with us a anymore.  At
1200 baud, the `window of vulnerability' as Reagan would put it, was
wider than at 9600, so while it happened to our modems all the time,
we never saw the problem with our hardwired ports.

Now after that backgroud, the query: Has anyone out there seen things
like this before with System III or System V, and is it really supposed
to work that way? No waiting, just change the baud rate in the middle of
a transmission? It forces us to put in some ugly code to wait for the
next xmit interrupt from that port, and it's messy.

The other question that comes to mind is why did USG choose to eliminate
the `ttyrend' interface for canonicalization of a buffer full of input?
As you might guess, that would be perfect for our serial board. As it is
we forced to do something like this:

	while((c = getc(FIFO)) != NO_MORE)
		(*linesw[tp->t_line].l_input)(tp, c);

when something more like this

	while((c = getc(FIFO)) != NO_MORE)
		buf[n++] = c;
	(*linesw[tp->t_line].l_rend)(tp, buf, n);

would be desireable. These are, of course, metaphorical code fragments.

I would appreciate any & all comments.

	Erik E. Fair

	dual!fair@BERKELEY.ARPA
	{ucbvax,ihnp4,cbosgd,amd70,zehntel,fortune,unisoft,onyx,its}!dual!fair
	Dual Systems Corporation, Berkeley, California