Re: ukbd: short freeze when activating LEDs

Maksim Yevmenkin wrote:
> On Sun, Oct 18, 2009 at 10:14 AM, Chris Ruiz <yr.retarded_at_gmail.com> wrote:
>> On Sun, Oct 18, 2009 at 7:50 AM, Stefan Ehmann <shoesoft_at_gmx.net> wrote:
>>> On Saturday 05 September 2009 20:29:29 Ed Schouten wrote:
>>>> * Hans Petter Selasky <hselasky_at_c2i.net> wrote:
>>>>> On Saturday 05 September 2009 16:32:55 Stefan Ehmann wrote:
>>>>>> Whenever I press capslock/numlock, the system shortly (< 0.5 ms)
>>>>>> freezes.
>>>>> It might also be because the USB keyboard driver is using Giant, which
>>>>> can be congested.
>>>> For half a second? I experience the same issue. I also have the same
>>>> issue with the Syscons VGA driver when switching windows. Some time ago
>>>> I talked about this with some other people and it may be possible it has
>>>> something to do with SMIs. Not sure...
>>>>
>>> Recently, I got an off-list response pointing me the "Other" section of
>>> http://wiki.freebsd.org/BugBusting/Commonly_reported_issues:
>>> "When switching consoles (e.g. Alt-F2 to switch to ttyv1), a 2-3 second delay
>>> is experienced"
>>>
>>> The suggested workaround (hint.kbdmux.0.disabled="1") also helps in my case.
>>> So it's not necessarily USB-related.
>> I'm my experience the "switching consoles" delay goes away when you
>> remove atkbd and related options from your kernel if you only have a
>> usb keyboard.  I don't have that delay with kbdmux left compiled in.
>> The delay most likely has something to do with locking, re: GIANT.
> 
> that's somewhat right, actually.
> 
> last time i looked into this, nor usb nor kbdmux(4) had really nothing
> to do with the delay. all kbdmux(4) does is executes the same command
> on all the keyboards attached to the mux. in this particular case,
> console switching, led toggling, etc. triggers series of ioctl()
> calls.
> 
> now, atkdb(4) is "special" is a way that it can be instructed to
> attach even if no actual keyboard is present. obviously this is done
> so it is possible to "hot-plug" keyboard and have it work. so, when
> kbdmux(4) tries to execute ioctl() on non-existent keyboard, atkbd(4)
> is basically trying to send data to a non-existent hardware and times
> out. the later is basically the delay people experiencing.
> 
> it is really NOT required to disable kbdmux(4) completely. just remove
> atkbd(4) from the mux using kbdcontrol(1). it should have exactly the
> same effect.
> 
> once again, all of the above applied only to the case when kbdmux(4)
> is used with non-existing atkbd(4) keyboard.

On one of my systems disabling USB legacy keyboard emulation in BIOS
solved the problem.

-- 
Alexander Motin