[comp.bugs.4bsd] TANDEM mode bugs in 4.3bsd

feldman@tymix.UUCP (Steve Feldman) (01/08/87)

Index:	sys/sys/tty.c 4.3BSD +FIX


Description:
	There are two problems in the TANDEM mode handling in the
	4.3 bsd tty driver.  (They were in 4.2 as well.)

	First, if you have a device which is slow responding to
	a control-S, the driver can send additional control-S's
	when the last few characters arrive.

	Second, there is a deadlock condition possible if the tty
	is in cooked mode.  If input is stopped with more than TTYHOG/5
	characters left in the rawq, input can't ever be started again
	since the application won't see those characters.

Repeat-By:
	Send lots of data to a slow system in cooked mode.

Fix:
	Apply the following patch to /sys/sys/tty.c:
		(your line numbers will vary.)

*** tty.c.old	Thu Jan  8 11:09:58 1987
--- tty.c	Mon Jan  5 17:33:13 1987
***************
*** 191,197 ****
  	 * Current input > threshold AND input is available to user program
  	 */
  	if (x >= TTYHOG/2 && 
! 	    ((tp->t_flags & (RAW|CBREAK)) || (tp->t_canq.c_cc > 0))) {
  		if (putc(tp->t_stopc, &tp->t_outq)==0) {
  			tp->t_state |= TS_TBLOCK;
  			ttstart(tp);
--- 191,198 ----
  	 * Current input > threshold AND input is available to user program
  	 */
  	if (x >= TTYHOG/2 && 
! 	    ((tp->t_flags & (RAW|CBREAK)) || (tp->t_canq.c_cc > 0)) &&
! 	    (tp->t_state&TS_TBLOCK) == 0) {
  		if (putc(tp->t_stopc, &tp->t_outq)==0) {
  			tp->t_state |= TS_TBLOCK;
  			ttstart(tp);
***************
*** 1245,1251 ****
  	 * Look to unblock output now that (presumably)
  	 * the input queue has gone down.
  	 */
! 	if (tp->t_state&TS_TBLOCK && tp->t_rawq.c_cc < TTYHOG/5)
  		if (putc(tp->t_startc, &tp->t_outq) == 0) {
  			tp->t_state &= ~TS_TBLOCK;
  			ttstart(tp);
--- 1246,1254 ----
  	 * Look to unblock output now that (presumably)
  	 * the input queue has gone down.
  	 */
! 	if (tp->t_state&TS_TBLOCK &&
! 	    (tp->t_rawq.c_cc+tp->t_canq.c_cc < TTYHOG/5 ||
! 	    (t_flags&(RAW|CBREAK)) == 0 && tp->t_canq.c_cc == 0))
  		if (putc(tp->t_startc, &tp->t_outq) == 0) {
  			tp->t_state &= ~TS_TBLOCK;
  			ttstart(tp);

brian@sdcsvax.UCSD.EDU (Brian Kantor) (01/10/87)

In article <973@tymix.UUCP> feldman@tymix.UUCP (Steve Feldman) writes:
>Description:
>	There are two problems in the TANDEM mode handling in the
>	4.3 bsd tty driver.  (They were in 4.2 as well.)
>
>	First, if you have a device which is slow responding to
>	a control-S, the driver can send additional control-S's
>	when the last few characters arrive.

This may not be a bug, depending upon how you view it.  It is ALSO
possible for the remote device to lose the XOFF character which means
that you MUST send it again or it will NEVER stop.  Very very few devices
queue an incoming XOFF, which means that extra ones don't hurt and are
likely more often to help.

Conjecture:
What may have prompted this is using terminal i/o with TANDEM set to
communicate with some other computer system which does not obey the same
XOFF/XON semantics as Unix does.  CP/M systems, for example, use XOFF to
stop output, but will restart it again on ANY character, including
another XOFF.  In this situation, the behaviour of TANDEM is not
optimal.  But the real solution may be to fix the remote host/device.

	Brian Kantor	UCSD Office of Academic Computing
			Academic Network Operations Group  
			UCSD B-028, La Jolla, CA 92093 USA

roy@phri.UUCP (Roy Smith) (01/12/87)

In <2439@sdcsvax.UCSD.EDU> brian@sdcsvax.UCSD.EDU (Brian Kantor) writes:
> Very very few devices queue an incoming XOFF, which means that extra
> ones don't hurt and are likely more often to help. [...]
> What may have prompted this is using terminal i/o with TANDEM set to
> communicate with some other computer system which does not obey the same
> XOFF/XON semantics as Unix does.  CP/M systems, for example, use XOFF to
> stop output, but will restart it again on ANY character, including
> another XOFF.

	A historical interest note: on vanilla v6 UNIX, XOFF was a toggle;
send one XOFF to stop output, another to restart it.  Given that v6 didn't
come with a pager program, the small amount of time saved by not moving
your fingers on the keyboard was important at 9600 baud.  One of my first
kernel hacks was to add "normal" XON/XOFF processing to the v6 tty driver.
-- 
Roy Smith, {allegra,cmcl2,philabs}!phri!roy
System Administrator, Public Health Research Institute
455 First Avenue, New York, NY 10016

"you can't spell deoxyribonucleic without unix!"

guy%gorodish@Sun.COM (Guy Harris) (01/13/87)

> 	A historical interest note: on vanilla v6 UNIX, XOFF was a toggle;
> send one XOFF to stop output, another to restart it.  Given that v6 didn't
> come with a pager program, the small amount of time saved by not moving
> your fingers on the keyboard was important at 9600 baud.

Vanilla V6 didn't have *any* support of XOFF, whether with XON or not.  Then
again, I don't think many people ran truly vanilla V6 (as in "read it in off
the tape and don't go near the source").