Date: Sun, 17 Nov 1996 11:27:16 +1100 From: Bruce Evans <bde@zeta.org.au> To: current@FreeBSD.org, nate@mt.sri.com Subject: Re: UserConfig is broken + PS/2 support success Message-ID: <199611170027.LAA00201@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>UserConfig is now broken in current. It may have to do withe the recent >syscons changes, but in any case nothing happens at the "config>" prompt >when I type anymore. The sources are from early this morning, so it's >probably a fairly recent change. This is (at least) because sc_port is not initialized until scprobe() is called much later. There is no keyboard at port 0. I don't like the new keyboard driver much. It's has too many features, and too many spinloops. Some of the flags and flags testing seem to be wrong: 1. KBD_DISABLE_AUX_PORT 0x20 According to Van Gilluwe, on ISA/EISA keyboards setting this gives: "Ignore parity from keyboard, no scan code conversion" [not the default]. This is now used. It seems to be harmless. It was also used in pccons. It is still defined in /sys/i386/isa/ic/i8042.h (which is where all the i8042-specific defines should always have been) as KC8_OLDPC 0x20 /* old 9bit codes instead of new 11bit */ 2. KC8_IGNSEC 0x08 /* ignore security lock */ [in i8042.h] This silently went away. Now syscons honors the security lock switch like most drivers. The PROBE_KEYBOARD_LOCK feature in the bootstrap works better with old buggy behaviour. 3. KBDS_CONTROLLER_BUSY 0x0002 aka KBS_IBF 0x02 According to Van Gilluwe and all other docs and drivers that I've seen, this bit is for "The motherboard controller's input buffer is full ... no writes should occur to ports 60h or 64h or the data/command will be lost". It has nothing to do with the controller's output buffer (i.e., scancodes for the driver to read). This bit is spun on for up to 100 msec in wait_while_controller_busy() which is (incorrectly) called from read_kbd_data_no_wait(). Not good for a no-wait routine in an interrupt handler. Calling it a "busy" bit encourages this error. --- The wait_until_controller_is_really_idle() function seems to be unusable. E.g., when it use used for a LED update,, interrupts are disabled, so it is guaranteed to spin if a scancode arrives. The LED update will succeed after a delay of a couple of hundred msec because it ignores the return code. The empty_*_buffer*() functions are broken. They miss scancodes that arrive a microsecond after the test and are almost certain to miss all but the first of a bunch of scancodes - the controller is unlikely to be able to deliver another scancode on the 0-20 usec delay time, especially if the keyboard is a few msec away from sending it! See pcvt_kbd.c for a working version (which is unsuitable for general use because of the lengthy spinloop). write_kbd_command() ignores the return code from wait_until_controller_is_really_idle(). Apart from the buggy interface (see above), this is critical for issueing the reset command - it is possible for the keyboard to hang and resetting it fixes it. I think the return code should not be ignored for other commands - the keyboard should be reset and reinitialized in this case. The 7us delays that are said to be necessary for MCA keyboards aren't there. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611170027.LAA00201>