Re: ukbd: short freeze when activating LEDs

From: Maksim Yevmenkin <maksim.yevmenkin_at_gmail.com>
Date: Mon, 19 Oct 2009 07:54:16 -0700
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.

thanks,
max

>
> -- Chris
>
> -----------------------------------------
> http://twitter.com/chrisattack
> http://chrisattack.com
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Mon Oct 19 2009 - 12:54:17 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:57 UTC