Fix the keyboard lockup problem. There were two big clues: The first was a
authorMatthew Dillon <dillon@dragonflybsd.org>
Thu, 16 Dec 2004 08:30:15 +0000 (08:30 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Thu, 16 Dec 2004 08:30:15 +0000 (08:30 +0000)
commitc5e92a811877e1c71acddac8c532b927306e8da9
treeadbe90e3ebaa9006e6c622f049aa63cfc0dc3533
parent5fe88d64f7ef04f69e760672f884578cc13daaac
Fix the keyboard lockup problem.  There were two big clues:  The first was a
report that it sometimes seemed to occur during heavy video operations.  The
second was a set of kernel dates from Jansen Gotis and Michael Powell that
focused me in on the right part of the code.

Simply put, there is a hack for AT keyboards that polls the keyboard for
data 10 times a second in order to catch lost interrupts.  Lost interrupts
can occur because unlike other interrupts the AT keyboard interrupt is
edge-triggered.  This means that latency in the system can cause the
keyboard interrupt to retrigger before it is reenabled after an earlier
event but not cause any further interrupts.

There is a big hack in the system that polls for keyboard data 10 times a
second in order to detect this 'lost' interrupt case.  However, that code
was broken by the timeout->callout work I did on September 19th.  An
incorrectly placed callout_reset() stopped the polling code in its tracks.

Reported-by: Jeroen Ruigrok/asmodai <asmodai@wxs.nl>,
Chris Pressey <cpressey@catseye.mine.nu>,
Michael Powell <nightrecon@hotmail.com>,
Jansen Gotis <jtgotis@gmail.com>,
And others.
sys/dev/misc/kbd/kbd.c