The other day I had the opportunity to sit down at a real VT340
connected to the console port of an i386 NetBSD box (over at my
colleague Andreas').

This machine would apparently freeze while booting, never getting past
the point where 'init' tries to open /dev/console.

The problem of course was flow control related.

I first suggested getting rid of smooth-scroll and going back to the
proper jump-scroll necessary for handling console output, but that
didn't fix anything.  However you could still tell there was a flow
control problem because the output didn't seem to be scrolling fast
enough -- it would be jumpy, sometimes fast, sometimes frozen, but in
all the wrong places (eg. in the middle of a line).

When we increased the VT340's flow control low-water mark from 64 to 256
bytes (the max is 512) the problem "went away".  It also goes away if
you simply turn off flow control too, of course, but that's hardly a
final solution if you want to use the terminal after the fact for
something other than just viewing console messages.

Note that this is all with the console at just 9600bps.

I've occasionally seen something very similar with machines I've had
connected to terminal servers, and that's even after I hacked the com
driver, and the serial boot code, and anywhere else in the kernel I
could think of to make sure that the UART would not get stuck if the
terminal had flow-controlled it during boot (that was with 1.3.3).  On
those machines though the hang was usually sometime during the output
from /etc/rc, not immediately as init started), and simply pressing any
key would restore output.  Nothing but a BREAK would wake up the i386
(and that of course dumps you into DDB where a reboot is the only thing
that gets you anywhere).  I suspect that's because I normally have "ixon
ixoff ixany" modes set once /etc/rc gets going, but I'll bet "-ixany" is
the default beforehand.

Once we got the machine booted up fine and working I tried reproducing
the problem you described with shell prompt output (but in the way I'd
reproduced it on the sparc serial console).  Oddly, no go!  At least not
always like on the sparc.  You can tell pretty easy when the VT340 has
flow controlled if you've got the key repeat set fast enough and you've
got key click enabled.  The click sound changes beat when the flow
control happens.

However with a certain amount of prompt output there are sometimes big
fat backwards question-marks splattered in the output from when the
terminal is flow controlled....


Oh, and BTW, you really really do need and want "autowrap" enabled!  ;-)

I'd forgotten just how frustrating it is to use a terminal without
autowrap until I was trying to demonstrate to Andreas the long-prompt
command-line editing problem in ksh and I discovered that his VT340 also
had autowrap turned off!  The demonstration was failing because the
buggy behaviour was indistinguishable from not having editing enabled.
At least with autowrap enabled and editing disabled you can see what you
type if your typing needs to wrap around!  :-)


I'm going to take another look at the hacks I did to the com driver and
the serial boot code and see if I can't fix the flow-control during boot
problem once and for all....  Though I think the ultimate solution is to
re-introduce delay characters (i.e. stty's "cr? nl? tab? bs? ff? vt?"
modes).  They should never have been removed from termio[s] in *BSD (or
rather they should have been implemented!).  That way the console modes
could be set more properly by default for serial terminals and flow
control problems for kernel output could be avoided in the "proper" (er,
proven) way.  If I ever get that far I'll send-pr whatever I come up
with!  ;-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>