khym@bga.com said:
> So yeah, it does look like the mouse probe is causing problems...
> (BTW, isn't this why the PS/2 mouse driver was disabled in GENERIC
> back around NetBSD 1.2 or 1.3?) 

This might be one reason, the other one is that the mouse driver
allocated interrupt 12 even if no mouse was present. If the BIOS
had used irq 12 for a PCI device, one got an interrupt sharing
panic.
In the new driver I tried to figure out:
a) whether the keyboard controller has a mouse port at all,
   using an "aux port test" function, and if this succeeds:
b) whether a mouse responds at the port;
the mouse interrupt is only used if the mouse is found.

Unfortunately, in your hardware (a) succeeds - the keyboard
controller has appearently some private function there which
looks like a succeeding aux port test to the driver. (I hope
your hardware description leads to some documentation.)
The mouse probe then does something to the controller and/or
to the keyboard.
I didn't find a way to reset the keyboard controller.
The appended patch tries to read any data left over from the
mouse probe, and then resets the keyboard.
Can you try it, and if it helps, try both parts separately?

best regards
Matthias


Index: pckbc.c
===================================================================
RCS file: /cvsroot/syssrc/sys/dev/isa/pckbc.c,v
retrieving revision 1.12
diff -u -r1.12 pckbc.c
--- pckbc.c	1999/03/05 10:40:54	1.12
+++ pckbc.c	1999/11/05 14:23:02
@@ -475,6 +475,18 @@
 		printf("kbc: aux port test: %x\n", res);
 #endif
 
+	/* flush */
+	while (pckbc_poll_data1(iot, ioh_d, ioh_c, PCKBC_KBD_SLOT, 0)
+	       != -1);
+
+	/* reset keyboard */
+	{
+		u_char cmd[1], resp[1];
+		cmd[0] = 0xff;
+		pckbc_poll_cmd(t, PCKBC_KBD_SLOT,
+			       cmd, 1, 1, resp, 1);
+	}
+
 	/* enable needed interrupts */
 	t->t_cmdbyte |= cmdbits;
 	if (!pckbc_put8042cmd(t))