Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site phri.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!timeinc!phri!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: net.unix-wizards
Subject: Re: 750 not rebooting after panic
Message-ID: <208@phri.UUCP>
Date: Sat, 20-Apr-85 11:37:42 EST
Article-I.D.: phri.208
Posted: Sat Apr 20 11:37:42 1985
Date-Received: Sun, 21-Apr-85 06:26:47 EST
References: <9982@brl-tgr.ARPA>
Organization: Public Health Research Inst. (NY, NY)
Lines: 38

> We recently started having this problem (i.e., the boot sequence parks
> right before the "Automatic reboot ..." message).

	Well, since I got the answer to the same question when I posted
it a while ago, I suppose I should share it.

	If your console is at a baud rate that requires it to do
XON/XOFF (i.e. faster than 1200 for a LA-120 or LA-100) the following
happens:  During the auto-conf printouts the printer sends an XOFF.
Since the console tty driver isn't dealing with interrupts yet (does it
ever?), the XOFF never gets looked at.  When the printer catches up, it
sends an XON.  Since the receiver buffer register was never emptied of
the XOFF, the XON gets discarded and the overrun error flag is set.
When the system goes to print out the "Automatic reboot" message, you
are running a 'real' console tty driver.  Of course, what's waiting in
the rcvr buffer?  The leftover XOFF.  Hence the system waits for the XON
that it missed.  I hope I got all the details right.

	At any rate, the fix is to reduce the console baud rate.  When
we dropped ours from 2400 to 1200 (LA-120), everything started to work
fine.

	BTW, I think the way most devices do XON/XOFF is wrong, or at
least less than optimal.  We have an H/P-7470A plotter (one of the
best designed things I've ever seen for the money) which takes a
slightly different approach to things.  When its buffer starts to get
full, it send an XOFF, but doesn't assume that it got received and acted
upon.  If, after some interval, stuff is still comming in, it sends
another XOFF.  The same thing works one the other side.  When its buffer
is empty enough, it sends an XON.  If it doesn't get any more data after
some interval, it assumes the XON got lost and sends another one.

	Since XON and XOFF are not supposed to nest (i.e. a single XON
should restart output after an arbitrary number of XOFFs) this protocol
is far more stable than what most other terminals I've seen use.
-- 
allegra!phri!roy (Roy Smith)
System Administrator, Public Health Research Institute