Re: Keyboard repeat issues with Dell Optiplex 980s
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! I forgot to attach my dmesg - here it is! Copyright (c) 1992-2011 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.2-RC2 #1: Mon Jan 17 12:10:53 EST 2011 root@galvatron:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz (2660.02-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x98e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4082315264 (3893 MB) ACPI APIC Table: DELL B11K FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.0 irqs 0-23 on motherboard lapic0: Forcing LINT1 to edge trigger kbd1 at kbdmux0 acpi0: DELL B11Kon motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: PCI-PCI bridge irq 16 at device 3.0 on pci0 pci1: PCI bus on pcib1 vgapci0: VGA-compatible display port 0xdc80-0xdcff mem 0xf600-0xf6ff,0xe000-0xefff,0xf000-0xf1ff irq 16 at device 0.0 on pci1 nvidia0: GeForce GT 330 on vgapci0 vgapci0: child nvidia0 requested pci_enable_busmaster vgapci0: child nvidia0 requested pci_enable_io vgapci0: child nvidia0 requested pci_enable_io nvidia0: [ITHREAD] hdac0: NVidia (Unknown) High Definition Audio Controller mem 0xf7dfc000-0xf7df irq 17 at device 0.1 on pci1 hdac0: HDA Driver Revision: 20100226_0142 hdac0: [ITHREAD] pci0: base peripheral at device 8.0 (no driver attached) pci0: base peripheral at device 8.1 (no driver attached) pci0: base peripheral at device 8.2 (no driver attached) pci0: base peripheral at device 16.0 (no driver attached) pci0:
Re: Keyboard repeat issues with Dell Optiplex 980s
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. ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to freebsd-hardware-unsubscr...@freebsd.org
Re: Keyboard repeat issues with Dell Optiplex 980s
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 ___ freebsd-hardware@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hardware To unsubscribe, send any mail to freebsd-hardware-unsubscr...@freebsd.org
