Keyboard repeat issues with Dell Optiplex 980s
Steve Polyack
korvus at comcast.net
Wed Jan 19 14:51:44 UTC 2011
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.
More information about the freebsd-hardware
mailing list