temporary freezes when pressing capslock / numlock

Maksim Yevmenkin maksim.yevmenkin at gmail.com
Tue May 27 21:28:28 UTC 2008


On 5/27/08, Rick C. Petty <rick-freebsd at kiwi-computer.com> 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


More information about the freebsd-hackers mailing list