briggs@ninthwonder.com said:
> pcib0: VIA Technologies VT82C586 (Apollo VP) PCI-ISA Bridge (rev.
> 0x41) 

This chip has a keyboard controller integrated - let's guess
it is actually used. The description is available from VIA's
website (http://www.via.com.tw/pdf/productinfo/586b.pdf).
If the chip did really work as described in this manual,
it should work - the keyboard controller doesn't look more
strange than other keyboard controllers.
There is a "status" byte read at the beginning of the interrupt
handler. Bit 5 of it tells whether the pending data are
from the mouse port. This all looks OK in the manual and in
the code.
Can you print out the "stat" variable just after it was read
in pckbc.c:pckbcintr()? You can check it against the description
(port 64, at pg. 22 of 586b.pdf). If it looks suspicious, you
could try to put a KBD_DELAY before the line where it is read.
If this all doesn't help, hardwiring the "slot" variable
to zero should at least make your keyboard work (disabling
the mouse port). (There could be a more intelligent solution,
but let's see first whether we can get reasonable status byte
out of the controller.)

> Is the 1 in 'using irq 1 for kbd slot' different than the 1 in
> 'no dev for slot 1'?

Yes, these are different namespaces. The first '1' is the ISA
interrupt number for the keyboard interrupt. The "slot" number
refers to the 2 devices connected to the keyboard controller:
keyboard (slot 0) and mouse (slot 1).

> Is the mouse slot uninitialized?

There is not much to initialize - there is a port selftest
done which obviously succeeds for you. Then it is tried to
send a "reset" command to the connected device, which
fails (that's the "opmsprobe: command error" message).
If there is no mouse, the slot is left with interrupts
disabled, and no interrupt handler for irq 12 (the mouse
interrupt) is installed. (Keyboard and mouse interrupts
are handled by the same function.)

best regards
Matthias