Subject: Re: USB problems with USB mouses
To: NetBSD current-users <current-users@NetBSD.org>
From: Chris Tribo <ctribo@dtcc.edu>
List: current-users
Date: 11/22/2005 20:29:17
I loaded up a kernel from the latest sources and decided to try my  
luck with the bits added to ehci lately.

Devices are detected now in my limited testing, but hotplugging still  
doesn't work right 90% of the time.

Again, none of the usb controllers show interrupts being mapped in  
vmstat. Once I unplug an active device, plugging it into any port  
results in nothing. I've tried all 8 ports with known working devices  
and it doesn't get noticed. Does port disabled  == interrupt  
disestablish and abandon ship? usbd is doing its thing, but with no  
interrupts mapped in the kernel, we're just losing every one right? I  
see usb_discover firing off every few seconds. Whatever is on port 4  
on the ehci root hub is marked as "enabled" while all other ports are  
marked as "powered" if that means anything. One of the ports is  
connected to a USB2 hub, the rest directly to devices. Back to the  
older BIOS I guess.


-bash-3.00# vmstat -i
interrupt                                     total     rate
cpu0 softclock                                25587      105
cpu0 softnet                                    310        1
cpu0 softserial                                   1        0
cpu0 timer                                    25764      106
cpu0 FPU flush IPI                                2        0
cpu0 FPU synch IPI                                1        0
cpu0 TLB shootdown IPI                          582        2
cpu1 timer                                    24334      100
cpu1 timeset IPI                                243        1
cpu1 FPU synch IPI                                4        0
cpu1 TLB shootdown IPI                         1113        4
ioapic0 pin 6                                     1        0
ioapic0 pin 4                                     1        0
ioapic0 pin 16                                  285        1
ioapic0 pin 22                                  103        0
ioapic0 pin 14                                   35        0
ioapic0 pin 20                                 1146        4
Total                                         79512      327

-bash-3.00# dmesg | grep hci | grep pin
uhci0: interrupting at ioapic0 pin 21 (irq 9)
uhci1: interrupting at ioapic0 pin 22 (irq 5)
uhci2: interrupting at ioapic0 pin 18 (irq 3)
uhci3: interrupting at ioapic0 pin 23 (irq 10)
ehci0: interrupting at ioapic0 pin 21 (irq 9)

dmesg
...
ioapic0 at mainbus0 apid 8 (I/O APIC)
ioapic0: pa 0xfec00000, version 20, 24 pins
ioapic0: misconfigured as apic 0
ioapic0: remapped to apic 8
acpi0 at mainbus0
acpi0: using Intel ACPI CA subsystem version 20050408
acpi0: X/RSDT: OemId <DELL  , GX280  ,00000007>, AslId <ASL ,00000061>
acpi0: SCI interrupting at int 9
acpi0: fixed-feature power button present
acpi0: fixing up intr link \_SB_.LNKD
mpacpi: could not get bus number, assuming bus 0
...
PNP0C0F [PCI interrupt link device] at acpi0 not configured
PNP0C0F [PCI interrupt link device] at acpi0 not configured
PNP0C0F [PCI interrupt link device] at acpi0 not configured
PNP0C0F [PCI interrupt link device] at acpi0 not configured
PNP0C0F [PCI interrupt link device] at acpi0 not configured
PNP0C0F [PCI interrupt link device] at acpi0 not configured
PNP0C0F [PCI interrupt link device] at acpi0 not configured
PNP0C0F [PCI interrupt link device] at acpi0 not configured
PNP0C01 [System Board] at acpi0 not configured
PNP0C02 [Plug and Play motherboard register resources] at acpi0 not  
configured
PNP0103 [HPET Timer] at acpi0 not configured
...
ehci0 at pci0 dev 29 function 7: Intel 82801FB/FR USB EHCI Controller  
(rev. 0x03
)
ehci0: interrupting at ioapic0 pin 21 (irq 9)
ehci0: BIOS has given up ownership
ehci0: EHCI version 1.0
ehci0: companion controllers, 2 ports each: uhci0 uhci1 uhci2 uhci3
usb4 at ehci0: USB revision 2.0
uhub4 at usb4
uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1
uhub4: 8 ports with 8 removable, self powered
...
ehci0: handing over low speed device on port 1 to uhci0
uhub4: port 1, device disappeared after reset
ehci0: handing over low speed device on port 3 to uhci1
uhub4: port 3, device disappeared after reset
uhidev0 at uhub1 port 1 configuration 1 interface 0
uhidev0: DELL DELL USB Keyboard, rev 1.10/1.00, addr 2, iclass 3/1
ukbd0 at uhidev0: 8 modifier keys, 6 key codes
wskbd0 at ukbd0: console keyboard, using wsdisplay0
uhidev1 at uhub1 port 1 configuration 1 interface 1
uhidev1: DELL DELL USB Keyboard, rev 1.10/1.00, addr 2, iclass 3/0
uhidev1: 2 report ids
uhid0 at uhidev1 reportid 1: input=1, output=0, feature=0
uhid1 at uhidev1 reportid 2: input=3, output=0, feature=0
usb_new_device: set address 2 failed
uhub_explore: usb_new_device failed, error=SET_ADDR_FAILED
uhub0: device problem, disabling port 1
ehci_sync_hc: tsleep() = 35
usb_new_device: set address 2 failed
ehci_sync_hc: tsleep() = 35
uhub_explore: usb_new_device failed, error=SET_ADDR_FAILED
uhub4: device problem, disabling port 4 <-- turns off EHCI making the  
whole usb system inoperative
Searching for RAID components...
...

With six devices connected:
-bash-3.00# usbdevs -d -v
Controller /dev/usb0:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),  
Intel(0x8086), rev 1.00
   uhub0
port 1 powered
port 2 powered
Controller /dev/usb1:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),  
Intel(0x8086), rev 1.00
   uhub1
port 1 powered
port 2 powered
Controller /dev/usb2:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),  
Intel(0x8086), rev 1.00
   uhub2
port 1 powered
port 2 powered
Controller /dev/usb3:
addr 1: full speed, self powered, config 1, UHCI root hub(0x0000),  
Intel(0x8086), rev 1.00
   uhub3
port 1 powered
port 2 powered
Controller /dev/usb4:
addr 1: high speed, self powered, config 1, EHCI root hub(0x0000),  
Intel(0x8086), rev 1.00
   uhub4
port 1 powered
port 2 powered
port 3 powered
port 4 enabled
port 5 powered
port 6 powered
port 7 powered
port 8 powered



On Oct 31, 2005, at 6:36 PM, Lennart Augustsson wrote:

> As you say, this could be an interrupt routing problem.
> It's really difficult to debug without access to the hardware
> (and even the it can be hard).
>
> 	-- Lennart