I get this message "kbd_cmd: input char 47 lost" right before [...]
   Anyone else see this?  Any clue what it means and if I should care?

Well, since I wrote it...

It's a simple diagnostic from the keyboard handler which indicates that,
when polling, it had to drop an unrecognized byte in order to find the
ack or nak in the input stream.  When not polling (i.e. normal use after
autoconfig), this won't happen because the acks and naks are processed
by the interrupt handler, and any interspersed bytes will be processed
normally before them.

(Actually, this creates a couple of obscure but not serious race
conditions.  The `right' way to deal with it involves having both an
input and an output buffer, but that was too much hair for me to bother
with at the time for so little gain.)


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