>> In message <[EMAIL PROTECTED]> Mike Smith writes:
>> : It doesn't do anything to the keyboard, it just calls the BIOS to find
>> : out whether keys have been pressed.
>>
>> I've been seeing the hit <CR> twice fast problem for months.
>
>It's always been a problem; we don't understand the mechanics of it
>however. Susceptibility varies widely between systems, and the best
>hypothesis I've been able to come up with is that there are issues with
>taking interrupts in vm86 mode; possibly the BIOS is being re-entered in
>a fashion it doesn't like.
I wonder if the keyboard interrupt is blocked for a prolonged period
in the boot loader because of vm86, and quite a number of (up to 16 or
something) scan codes are waiting in the keyboard to be received by
the host computer, when the kernel is loaded.
The keyboard driver atkbd tries to flush pending scan codes, left over
from the boot loader, before it starts initializing the keyboard. It
may be failing to flush all the pending scan codes if there are too
many of them.
The following patch will make the driver wait slightly longer to flush
inputs. I would like to see if this makes any difference.
I should come up with something better this, though...
Kazu
Index: atkbd.c
===================================================================
RCS file: /src/CVS/src/sys/dev/kbd/atkbd.c,v
retrieving revision 1.22
diff -u -r1.22 atkbd.c
--- atkbd.c 2000/01/20 13:32:53 1.22
+++ atkbd.c 2000/01/28 00:47:27
@@ -1085,7 +1098,7 @@
}
/* flush any noise in the buffer */
- empty_both_buffers(kbdc, 10);
+ empty_both_buffers(kbdc, 200);
/* save the current keyboard controller command byte */
m = kbdc_get_device_mask(kbdc) & ~KBD_KBD_CONTROL_BITS;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
