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