Keyboard repeat issues with Dell Optiplex 980s

[Hans Petter Selasky]

On Wednesday 19 January 2011 15:51:41 Steve Polyack wrote:
> 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.

For FreeBSD 8+ this is not true. Probably the manpage has not been updated. 
Hence you are seeing a different number of UHCI controllers, this looks like 
an ACPI problem. USB keyboards usually require a UHCI to enumerate. The EHCI 
can only enumerate High Speed devices.

--HPS