Date: Mon, 26 May 2008 22:11:09 -0700 From: Jeremy Chadwick <koitsu@FreeBSD.org> To: "Rick C. Petty" <rick-freebsd@kiwi-computer.com> Cc: freebsd-hackers@freebsd.org, m_evmenkin@yahoo.com, Fraser Tweedale <frase@frase.id.au> Subject: Re: temporary freezes when pressing capslock / numlock Message-ID: <20080527051109.GA26502@eos.sc1.parodius.com> In-Reply-To: <20080527041236.GB68298@keira.kiwi-computer.com> References: <48378DA0.8040506@frase.id.au> <20080524201633.GA81364@eos.sc1.parodius.com> <20080527041236.GB68298@keira.kiwi-computer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 26, 2008 at 11:12:36PM -0500, Rick C. Petty wrote: > On Sat, May 24, 2008 at 01:16:33PM -0700, Jeremy Chadwick wrote: > > On Sat, May 24, 2008 at 01:38:08PM +1000, Fraser Tweedale wrote: > > > Since upgrading to RELENG_7_0 I was experiencing momentary freezes (of > > > about .5 seconds) whenever the capslock or numlock buttons were pressed. > > > > Let me guess -- you're using a USB keyboard. > > > > > The issue occurs both in console and in X, and for both ULE and 4BSD. The > > > problem was reproducible with USB keyboards only (ukbd); atkbd seems fine. > > > It also occurs when numlockx is used to set numlock on or off without > > > keyboard interaction. > > > > I figured as much. I hadn't checked numlock/capslock myself, but vcons > > switching also has that problem. Yes, it's semi-documented; see section > > "USB" below: > > > > http://wiki.freebsd.org/JeremyChadwick/Commonly_reported_issues > > > > For what it's worth, the systems I've confirmed the problem on are Intel > > and nForce 4. Meaning, the issue is not specific to a single chipset. > > I've seen this on certain chipsets (nForce4, Intel) and not on others > (nForce5+). I originally reported this problem over two years ago: > > http://lists.freebsd.org/pipermail/freebsd-hackers/2006-March/015724.html > > This problem started when the kbdmux was added to the kernel and has not > been fixed since (although the "delay" has been reduced from around two > seconds to about 0.4 seconds). I verified the problem still persists with > 7-stable as of last week. > > This "pause" actually blocks the entire kernel, not just things under > GIANT. One test involved having a gmirror sync or fsck run while I > switched virtal consoles and watched the drive activity LEDs turn off for > the entire duration of the pause. > > > > Interestingly, if you add enough keyboards, the problem vanishes, which led > > > me to kbdmux. Sure enough, removing device kbdmux from the kernel makes > > > the problem go away (at the expensive of some functionality of course, but > > > this is my current workaround). > > > > An interesting find! I'll add this to the details in the above wiki. > > I've also CC'd kbdmux's maintainer. > > I've noticed that even plugging in a PS/2 keyboard fixes the problem. > However unplugging the PS/2 keyboard restores the problematic behavior. > I never found a solution to this problem except for buying different > hardware or keeping a PS/2 keyboard plugged in. > > Being that the issue is on your wiki page, does that mean this problem will > be fixed some day? Hopefully. :-) I'd like to point fingers at kbdmux being the responsible piece, but the USB stack has a history of being flakey in many regards, hence my reluctance. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080527051109.GA26502>