[ On Monday, January 24, 2000 at 11:16:27 (-0800), Jonathan Stone wrote: ]
> Subject: Re: serial console HOWTO? 
>
> There's a good chance that between us, by 1.5, NetBSD's bootblocks
> will be even spiffier.

Unfortunately I haven't been able to jump in on this discussion earlier
or perhaps I might even have been able to head off some of the blind
alleys with an example of working code.

I'm remotely managing a number of iX86 based servers running 1.3.3 with
serial consoles (connected to DEC terminal servers in this case).  In
order to do that I had to "fix" the i386 boot blocks.  I posted those
fixes (with send-pr IIRC).  Unfortunately the primary goal of my changes
was erased from whatever was takend from those parts of them that were
incorporated into NetBSD.  That primary goal was to make console
selection automatic in the direction that makes the most sense,
regardless of whether that system is primarily intended to be used with
a serial console, or not.

What I did was to take the FreeBSD keyboard probe routine and
incorporate it into the i386 bootblock code and to make the default
compile build boot blocks that would always probe for the keyboard and
use it as the console only if it was present and to always to the first
available BIOS "com" port as the console if there was not keyboard.

This algorithm can only fail in a scenario where one uses a KVM switch
that doesn't have enough ports to leave one empty and where that switch
is not always left selecting the empty port, or in the case where a one
uses a sophisticated KVM switch which fakes the presence of a keyboard
at all times.  My solution was to just avoid KVM switches and train the
on-site people to always pull the keyboard plug out before rebooting to
multi-user mode.

Note that this algorithm also mimics almost exactly what Sun
workstations have done since almost the beginning too.  Requiring a
keypress on the serial console to select it is so bogus I can't even
begin to express my dislike of it.  There are many improvements that
could be made, some of which have been discussed in this thread, but it
is absolutely critical that the console device be automatically selected
in a default order that will normally end up on the first working serial
port if a keyboard and/or video adapter is not present.

I've been handing out copies of my boot blocks to many people in the
past year or so and everyone has been extremely happy with them.  My
only problem has been a Compaq 2500 server where the FreeBSD keyboard
probe fails for some reason.

Oh, there's another unrelated problem too, one that I think has already
been discussed, and that's an occasional "freeze" of serial output after
the init process starts that requires a character be sent fromthe
terminal.  I've done everything I thought I could to ensure that an XOFF
couldn't get things stuck but to no avail.  Since reading this thread
I've noted two possible points that could be causing problems.  First is
the revalation that the kernel doesn't do any flow control and the
second is that XON/XOFF isn't implemented properly.  I now suspect that
there's some chance that the UART might get stuck in XOFF mode if the
output buffer has not completely drained just as XOFF is enabled when
init starts up.

Now I do agree that there is much risk to the kernel if any form of flow
control can get stuck in the off state.  However it's not as simple as
just not doing flow control in the kernel because what happens is that
if a user turns on flow control on the console device then the kernel
will be forced to use it and will (and does) get stuck if the user
subsequently presses <CTRL-S> or pulls the plug or whatever.

I think this all adds up to the fact that the only type of flow control
that should ever be enabled on a serial console is hardware flow
control.  No form of software flow control should ever be used.  The
kernel should override any attempt to "stty ixoff/ixany" on the console
port.  If your output terminal cannot keep up and doesn't support any
kind of reliable hardware flow control then you'll simply have to reduce
the console baud rate until it can.  Furthermore hardware flow control
should have reliable and sensible timeouts to prevent freezing the
entire system when the plug is pulled.

Of course I'd love to have "srm" or "openfirmware/sunmon" style serial
support in an iX86 machine too, and perhaps the new Intel ServerBIOS is
sufficiently capable to work like this with appropriate boot and kernel
support but at least one must have the minimal boot and kernel support
for reliable serial console selection.

-- 
							Greg A. Woods

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