Will getty change speed from 9600 to 9600? (Altos out of C-Lists)

[Jim Rosenberg]

It's my understanding that getty implements break detection in a very
straightforward way:  Any ASCII null ('\0') will cause getty to toggle to the
next baud rate.  (The idea is presumably that a break will appear as nulls
with framing errors at any baud rate; attempting to actually detect the
framing error would involve fooling with BRKINT, which means getty would have
to catch a signal, and then you have the old second-signal-too-fast-ain't-
catchable bugaboo under pre V.3 System V.)  Suppose the gettydefs entry for
9600 is linked to itself.  Suppose getty gets a null as a garbage character --
such as when a terminal is turned on or a PC being used as a terminal is
rebooted.  Is getty smart enough to understand that it doesn't really have to
change speed from 9600 to 9600?  Or (as I suspect) will it dutifully go right
ahead to the "next" gettydefs entry as if it were a completely different entry
and issue the ioctl() to change the baud rate?

Here is why I ask.  I posted a previous message about getting a console
message on a new Altos 2000 that says Out of C-Lists even though the system is
just about unloaded, process-wise.  I had originally associated the message
with Kermitting at 9600 baud, but this seems to be an inaccurate narrowing of
the symptom.  I made that association because I had a 286 connected over a
serial line to the Altos; the 286 normally runs an operating system called
QNX, and at the moment the Kermits I've got for QNX are not great shakes, so I
would reboot the 286 to do file transfer under (ugh) Mess-DOS.  The other day
in bringing up a new release of QNX I had to reboot the 286 several times, and
the Out of C-Lists message showed up quite a few times.  In response to my
posting I got a couple of messages; it seems that other people are observing
that the message is happening when a terminal is turned on while getty is
talking to it.

Although I may be full of bulls**t, my current hypothesis of what is actually
going on re this Out of C-Lists message is as follows.  Despite my best
efforts at wishful thinking, the message is not spurious, the kernel really is
being run out of C-lists.  The Altos 1086, 2086, and 2000 all have a Serial
I/O (sio) processor with downloadable firmware.  The problem seems to be
happening on all of these machines, & I believe is happening over different
releases of Xenix.  I am guessing that there is a race condition in the sio
code, and that under some circumstances if a character or several characters
come in just as the sio processor is attempting to change baud rate, the sio
processor will lose its marbles over how many characters it has queued and
report back to the upper half of the driver a humongous number if input
characters, even though in fact there really aren't that many characters
there.  The kernel gags because it genuinely doesn't have enough C-lists for
all those phantom characters.

If I'm on the right track here, there *SHOULD* be a workaround by putting a
hack into getty that smartens it up about a gettydefs entry linked to iteslf.
Of course, if getty is already this smart then I'm full of hot air.  This
would be fixable if one has source (we don't!!) whereas even if you have a
source license I doubt Altos is letting source for the sio code out the door,
so only Altos can fix that.  This won't help for dialup lines that truly do
need to change baud rates; I haven't come up for login yet, so I haven't been
able to tell if a toggle among 1200 and 2400 causes the problem too.

Configuration rights for the 2000 go under the name of a product called the
Unlinked Kernel.  I haven't ordered that yet because we will want to be
running the new fancy Altos networking package (AdLanTes, or whatever) which
will require an upgrade to V.3, which I badly want anyway.  If someone out
there has the Unlinked Kernel for a 2000, can you tell me if the number of C-
Lists is tunable?  If so, throwing more C-lists at this problem might also
work.

Meantime:  Uh, Altos, knock knock, calling all cars, anybody home???  I don't
wanna flame anybody, but gosh and golly gee, Altos, this bug has been around
for months, and I mean I don't wanna impose on anybody, but shucks it sure
would be nice if you did something really wild and *fixed* the problem.

BTW:  Does anybody have a public domain V.2-compatible getty?
-- 
 Jim Rosenberg
     CIS: 71515,124                         decvax!idis! \
     WELL: jer                                   allegra! ---- pitt!amanue!jr
     BIX: jrosenberg                  uunet!cmcl2!cadre! /