Subject: Serial consoles: looking for test hardware
To: None <mellon@fugue.com>
From: Jonathan Stone <jonathan@DSG.STANFORD.EDU>
List: port-pmax
Date: 01/16/1996 15:28:52
The scc driver works fine for me, on a 5k/240.  I've run
it up to 56 Kbits.  I want to try it at 114.2 and see how it keeps up.

On slower machines, and machines like the 3MIN where NetBSD
makes all interrupt levels be splhigh(),  over-runs happen.
I don't see a simple fix for that.

The real problem that people are asking for is supporting
a serial consoe.   THe problem here is getting some memory,
pointing the serial driver at it, and getting the serial driver
set up.  This all has to happen early in boot, before autoconfig
does its thing, and even before malloc() can be called.

CGD's suggestion is to have one static softc element per driver, and
use that softc for console ports.  The autoconfiguration procedure
needs to be educated to not step on that softc when it comes time
to try  and autoconfigure the serial port that's already running
as a serial console.

I was lazy.  I punted.  I haven't had time, and it's not been
a priority.  (My apologies.)  For now, the serial drivers don't
do any pre-autoconfig configuration whatsoever.   What happens is,
if the kernel decides a serial console should be used, then
it continues to  use the PROM output, up until the serial line
acting as a console is auto-configured, at which point it tries
to switch over to the native kernel driver.   Or, at least, 
it should.

Simon's message is saying the switch never happens.  It may
be that the SCC driver isn't detecting that scc1 is acting
as a console; or the drain-the-PROM-and-switch-the-cndev
code may be  broken.

Someone once offered me a loaner machine (a MAXINE) if it would
help me fix this problem.   I'm now at a point where I could
take that up, if the offer still stands.

--Jonathan