>> (1) I have been unable to get logins working on /dev/ttya.  I turn
>>     it on in /etc/ttys, HUP init, and the login prompt shows up
>>     fine.  Then I type a username and RETURN (which echo correctly),
>>     and it says [...] @8@@@@9w [...]

Several people have told me I need to change :ap: to :np: in some
relevant entry in gettytab.  I did this, and it started working.  (I
didn't suspect parity because "@8@@@@9w" isn't "Password: " with half
the characters garbled, which is what I'd expect out of a parity
problem.  I'd expect either "P???wor?:?" or "?ass???d? ", where ?
represents a garbled character.)  One person pointed out that the stty
settings are cs7 -parenb when it's getting garbled, which is perhaps
relevant.

However, there's now a new problem.  Upon changing :ap: to :np: in
gettytab, everything appeared to work...except that now it occasionally
drops characters on output.  Not often; probably <1% of output
characters are dropped.  The only thing I've been able to see that they
have in common is that it's always exactly one character dropped, and
it's early in the output of something.  For example, my prompt begins
[Callisto] and it often shows up as [Calisto].  This happens only on
the serial lines, never on the console or on a network login from
elsewhere.

I suspect it has something to do with setting tty modes; my postulated
mechanism is as follows: a program queues a blip of output; the zs
driver starts trickling it out the serial line.  A few character times
later, the shell regains control.  Preparatory to reading anything, it
sets the tty state to CBREAK, ~ECHO, all special characters disabled
except t_stopc and t_startc.  I conjecture that a bug somewhere in the
tty or (more likely) zs code causes this setting operation to lose an
output character.

Anyone have any idea what could be going on here?

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu

------------------------------------------------------------------------------