Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site gatech.CSNET
Path: utzoo!watmath!clyde!burl!ulysses!gatech!spaf
From: spaf@gatech.CSNET (Gene Spafford)
Newsgroups: net.unix-wizards,net.bugs.4bsd
Subject: Re: UDA50 problems
Message-ID: <2291@gatech.CSNET>
Date: Wed, 18-Dec-85 14:49:47 EST
Article-I.D.: gatech.2291
Posted: Wed Dec 18 14:49:47 1985
Date-Received: Thu, 19-Dec-85 05:19:10 EST
References: <296@tikal.UUCP>
Reply-To: spaf@gatech.UUCP (Gene Spafford)
Distribution: net
Organization: The Clouds Project, School of ICS, Georgia Tech
Lines: 50
Xref: watmath net.unix-wizards:16154 net.bugs.4bsd:1889

In article <296@tikal.UUCP> stan@tikal.UUCP (Stan Tazuma) writes:
>Other:
>	Out of 3 identical installations, we get these error
>	messages on only one.  The system doesn't crash when
>	these messages occur, but peculiar things happen (like
>	the autoboot sequence pausing (until a key is hit)
>	just before /etc/rc is run (no, we don't have rc prompt
>	for anything)).
>
>Anybody have experiences with these errors?

I'm afraid I can't help you with your disk errors, but I can tell you
why your system hangs during autoboot.

The printing console you get with the 750 (probably a LA100-type) can't
take characters at the rate the controller is strapped for.  When any
significant amount of output is transferred to the console before the
system comes up, the terminal sends a control S to the system to stop
the output to prevent a buffer overflow.  So far, so good.  The console
catches up and sends a control Q to restart output (the output never
really stops since nothing is paying attention to the console at the
moment).  Unfortunately, since Unix isn't back up, it hasn't issued the
command to fetch the control S out of the console input register.  The
control Q gets tossed away and the overrun bit is set.

Now the system continues on its merry way and suddenly comes up far enough
to poll the console.  Lo, there's a control S (it never checks the
overrun bit)!  It processes the control S and "stops" output.  Eventually,
the buffer fills up and Unix hangs in the reboot code as it tries to
put more characters into the buffer.  Typing any character causes
the driver to start printing again.

Fixes in order of preference:
Setting the console to draft/letter mode button to the setting 
opposite to what you have sometimes works (set it to draft?  I'm
at home at the moment and can't remember which setting is needed).

Change the kernel to either have a bigger console buffer, or check
that the character fetched is a control S and the overrun bit is set,
or that the first character ever fetched is a control S.

Configuring the terminal with the "setup" key to not use control
S/Q  (not good, since this will scramble later output).

Hope that helps!
-- 
Gene "the end is in sight" Spafford
The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332-0280
CSNet:	Spaf @ GATech		ARPA:	Spaf%GATech.CSNet @ Relay.CS.NET
uucp:	...!{akgua,decvax,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf