Date: Mon, 19 Oct 2009 23:45:14 +0300 From: Alexander Motin <mav@FreeBSD.org> To: current <current@freebsd.org> Subject: Re: ukbd: short freeze when activating LEDs Message-ID: <4ADCCFDA.3020706@FreeBSD.org> In-Reply-To: <mailpost.1255964119.3031439.26651.mailing.freebsd.current@FreeBSD.cs.nctu.edu.tw> References: <200909051806.07692.hselasky@c2i.net> <20090905182929.GB2829@hoeg.nl> <200910181450.11838.shoesoft@gmx.net> <58c737d70910181014u7c32ffd2s8c0732a707d40a2f@mail.gmail.com> <mailpost.1255964119.3031439.26651.mailing.freebsd.current@FreeBSD.cs.nctu.edu.tw>
next in thread | previous in thread | raw e-mail | index | archive | help
Maksim Yevmenkin wrote: > On Sun, Oct 18, 2009 at 10:14 AM, Chris Ruiz <yr.retarded@gmail.com> wrote: >> On Sun, Oct 18, 2009 at 7:50 AM, Stefan Ehmann <shoesoft@gmx.net> wrote: >>> On Saturday 05 September 2009 20:29:29 Ed Schouten wrote: >>>> * Hans Petter Selasky <hselasky@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ADCCFDA.3020706>