From owner-freebsd-stable@FreeBSD.ORG Wed Jan 19 14:51:44 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5F6B1065670 for ; Wed, 19 Jan 2011 14:51:43 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from mx03.pub.collaborativefusion.com (mx03.pub.collaborativefusion.com [206.83.220.142]) by mx1.freebsd.org (Postfix) with ESMTP id C50478FC33 for ; Wed, 19 Jan 2011 14:51:43 +0000 (UTC) Received: from Internal Mail-Server by mx03 (envelope-from korvus@comcast.net) with SMTP; 19 Jan 2011 09:46:00 -0500 Message-ID: <4D36FA7D.1030503@comcast.net> Date: Wed, 19 Jan 2011 09:51:41 -0500 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101109 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Jeremy Chadwick References: <4D3608BD.7010604@comcast.net> <20110118225617.GA16727@icarus.home.lan> <4D36EB91.1050406@comcast.net> In-Reply-To: <4D36EB91.1050406@comcast.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable , User Questions , freebsd-hardware@freebsd.org Subject: Re: Keyboard repeat issues with Dell Optiplex 980s X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 14:51:44 -0000 On 01/19/11 08:48, Steve Polyack wrote: > On 1/18/2011 5:56 PM, Jeremy Chadwick wrote: >> On Tue, Jan 18, 2011 at 04:40:13PM -0500, Steve Polyack wrote: >>> We've recently upgraded a few desktop workstations from Dell >>> Optiplex 960s to Optiplex 980s. We were running FreeBSD >>> 8.1-RELEASE. The migration was performed by simply swapping the >>> drives into the new systems. Immediately after switching people >>> over, they all began to report bizarre keyboard issues - things like >>> infinite key repeats (letters, numbers, "enter") for keys they did >>> not hold down. The key repeats continue indefinitely until another >>> key is pressed. Occasionally, even mouse input will trigger similar >>> infinite keyboard input repetition. In addition to the repeat >>> issue, sometimes physical key-presses are not registered by FreeBSD, >>> leading to typos and angry developers. >>> >>> We've tried doing fresh installs of FreeBSD 8.2-RC2 on two of these >>> systems, and the issue persists. Because of the observed behavior, >>> I'm thinking that this is due to new hardware in the 980s which >>> isn't timing or handling interrupts correctly under the FreeBSD >>> kernel. >>> >>> Looking at a 'pciconf -lvb' from each system, I noticed that the 980 >>> has two USB controllers which probe under ehci(4), while the 960 >>> (which does not exhibit this problem), enumerates six uhci(4) >>> controllers and two ehci(4) controllers. To cut to the chase here, >>> the 960 users' keyboards probe under a USB1.0 uhci(4), while the >>> 980s only have ehci(4) devices to attach to. >>> >>> So, I guess what I'm asking is - has anyone else seen any keyboard >>> repeat or other USB craziness with ehci(4) ports or otherwise Intel >>> PCH controllers? Any fellow Optiplex 980 users? I'd be more than >>> happy to provide pciconf or other output if requested. >> Try adding the following to /boot/loader.conf then reboot and see if >> the "excessive repeat" behaviour changes: >> >> hint.kbdmux.0.disabled="1" >> >> It would also help if you would state exactly what brand/model of >> keyboard is used. Yes, believe it or not, it matters. dmesg output >> would be helpful in this case. >> > The keyboard is also a Dell model - model KB1421, or listed as "Dell > QuiteKey Keyboard" under dmesg. The same keyboard does not exhibit > the strange behavior when used with the older model of tower (Optiplex > 960). > > I'll reboot today with the loader.conf hint you provided. I'll let > you guys know if it helps. Thanks! > The problem still exists with the kbdmux.0.disabled hint. It definitely took effect, as there is no longer a /dev/kbdmux0, and dmesg lists the refusal to register the kbdmux module. Any other ideas? We've tried playing with the hw.usb.ehci.lostinrbug and hw.usb.ehci.no_hs sysctls, but they don't make a difference either. Looking at the ehci(4) man page, this sticks out at me: BUGS The driver is not finished and is quite buggy. There is currently no support for isochronous transfers.