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