diff options
| author | emax <emax@FreeBSD.org> | 2006-02-25 21:59:29 +0000 |
|---|---|---|
| committer | emax <emax@FreeBSD.org> | 2006-02-25 21:59:29 +0000 |
| commit | 9245bd4f77e8db1a0e1e578aa0f025118a4b9eff (patch) | |
| tree | 7ce9b879f702d0662457c773632de8c8cef69675 /sys/dev/kbdmux | |
| parent | 206a96b4dbe1d804bf506746dc77748fc4c9ae41 (diff) | |
| download | FreeBSD-src-9245bd4f77e8db1a0e1e578aa0f025118a4b9eff.zip FreeBSD-src-9245bd4f77e8db1a0e1e578aa0f025118a4b9eff.tar.gz | |
Fix hard lockup caused by kbdmux(4) when kbdmux(4), PS/2 keyboard
(atkbd(4)) and PS/2 mouse (psm(4)) are used together.
Turns out that atkbd(4) check_char() method may return "true" while
read_char() method returns NOKEY. When this happens kbdmux(4) was
simply stuck in the dead loop. Avoid dead loop in kbdmux(4) by breaking
out of the loop if read_char() method returns NOKEY.
It almost seems like a bug in atkkbd(4), atkbd_check_char() calls
kbdc_data_ready(), and, the later will return "true" if there are
pending data in either kbd or aux queue. However, because both aux
and kbd are on the same controller, I'm not sure if this is a bug
or feature.
Tested by: markus
MFC after: 1 day
Diffstat (limited to 'sys/dev/kbdmux')
| -rw-r--r-- | sys/dev/kbdmux/kbdmux.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/sys/dev/kbdmux/kbdmux.c b/sys/dev/kbdmux/kbdmux.c index 8d99791..844baa7 100644 --- a/sys/dev/kbdmux/kbdmux.c +++ b/sys/dev/kbdmux/kbdmux.c @@ -250,7 +250,7 @@ kbdmux_kbd_event(keyboard_t *kbd, int event, void *arg) while (KBDMUX_CHECK_CHAR(kbd)) { c = KBDMUX_READ_CHAR(kbd, 0); if (c == NOKEY) - continue; + break; if (c == ERRKEY) continue; /* XXX ring bell */ if (!KBD_IS_BUSY(kbd)) |
