On 5/27/08, Rick C. Petty <[EMAIL PROTECTED]> wrote: > On Tue, May 27, 2008 at 01:32:10PM -0700, Maksim Yevmenkin wrote: > >
[...] > > i suspect that because physical ps2 keyboard is not actually > > present, the atkbd driver will have to timeout while talking to > > non-present hardware. > > Sure, but this timeout shouldn't be ~0.4 seconds. I believe the spec says > the maximum wait period to tell if the device is nonresponsive is around or > less than 20ms. Certainly, blocking the entire kernel for the timeout is a > bad thing, especially since the driver should make full use of the > asynchronous onboard keyboard controller. well, i just took a brief look at atkbd(4). specifically one function - wait_while_controller_busy(). this function polls status every KBDC_DELAYTIME (20) usec with retry count of 5000. so, just this function alone can give up to 100 msec delay. keep in mind that wait_while_controller_busy() is apparently called every time driver need to talk to the hardware. i can see how we could delay kernel for 400 msec or even more. > > so, as a suggestion, please try to specify 0x1 flag to atkbd, i.e. from > atkbd(4) > > ... > > > > and see if this helps. you wont be able to "hot plug" ps2 keyboards, > > but i suspect you probably can live without it. > > I'm almost certain this will help, but I believe this shouldn't be the > answer to this problem. There's no reason atkbdc(4) should block the > entire kernel for any appreciable amount of time. agree. all i was trying to say is that kbdmux is only as good as underlying low level keyboard drivers. if a low level keyboard driver uses completely synchronous approach to poll the hardware, there is not much kbdmux can do about it. thanks, max _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
