On Mon, 20 Apr 2009, Stuart wrote: > Hello! > > I'm trying to determine why the remote control included with my DigitalNow > TinyTwin DVB-T tuner connected to a USB port on an Abit IC7-MAX3 motherboard is > not working properly and am looking for some help to solve the problem. I > believe the problem may be in the PCI/interrupt handling region, however, I see > different behaviour between uhci_hcd and ehci_hcd so I thought I should start > there. Which version of the Linux kernel are you using? > The tuner is a USB2 device with two interfaces, the interface corresponding to > the remote is correctly identified as class HID (keyboard) and uses the usbhid > driver. > > I believe the main issue is that pressing and releasing a key on the remote > generates a key press but the key release arrives some time later. With uhci_hcd > this is ~0.27-0.3s after the key press while with ehci_hcd it is ~17.4s (on > Windows the usb sniff appears to show ~0.09s). In both cases it leads to auto- > repeating with the default usbhid driver. Another issue seems to be that > pressing any key after the first key press but before the corresponding key > release appears as the original key pressed a second time, leading to missed key > presses. It's obviously much easier to see this with 17.4s between key press and > release but is still easily possible with 0.272s. > > With both uhci_hcd and ehci_hcd I can see that the probe function used is > usb_hcd_pci_probe in drivers/usb/core/hcd-pci.c, this calls usb_add_hcd in > drivers/usb/core/hcd.c which calls request_irq using usb_hcd_irq as the function > to call on an interrupt. The drivers register functions ehci_irq and uhci_irq to > handle the interrupts from usb_hcd_irq. I've placed printk's in the relevant > files to track the delay between press and release which seems to be before > usb_hcd_irq is called, leading me to believe there is possibly a problem in the > PCI/interrupt handling region. That is possible, but I rather doubt it. > I'm wondering if the way interrupts are initialised in usb_hcd_pci_probe (due to > flag HCD_MEMORY it's request_mem_region/ioremap_nocache for ehci_hcd and > request_region for uhci_hcd) could be causing differences between uhci_hcd and > ehci_hcd? Probably not. Neither request_mem_region, ioremap_nocache, nor request_region bears any relation to interrupts. The real initialization is done by request_irq() for both drivers. > Could the value of bInterval for the interrupt endpoint being > interpreted differently for uhci_hcd and ehci_hcd (as per the spec) have an > effect? It certainly could. > The value is 16 which corresponds to an interval of 16ms for uhci_hcd > and 4096ms for ehci_hcd. Also, usbmon seems to show 8192 for the interval with > ehci_hcd. That means 8192 microframes, which is 1024 ms. Of course this doesn't explain the reason for the 17-second delay. You might try patching the usbhid driver to fix the interval value in the high-speed descriptor (set it to 8 for a 16-ms period, or even 4 for a 1-ms period). It will be interesting to see how that affects the behavior. > Or is all of this a problem further down the chain with PCI and/or interrupts? I would guess from your /proc/bus/usb/devices listings that at least part of the problem is in the device itself; the value it gives for the high-speed interrupt interval is encoded wrongly. Beyond that there simply isn't enough information here to tell where the real problem lies. You would have to use a USB bus analyzer to see if the data is really being sent faster than the usbmon log indicates. > Any help would be appreciated, thanks in advance! > > Stuart > > (UHCI) cat /sys/kernel/debug/usbmon/1u: > > d3499880 1067303301 C Ii:1:002:3 0:16 8 = 00001e00 00000000 > d3499880 1067303337 S Ii:1:002:3 -115:16 8 < > d3499880 1067575252 C Ii:1:002:3 0:16 8 = 00000000 00000000 > d3499880 1067575286 S Ii:1:002:3 -115:16 8 < Here the delay between press and release is just about 272 ms, almost exactly 16 ms times 17. This strongly suggests that the device really did wait for a while before sending the key release data. > (EHCI) cat /sys/kernel/debug/usbmon/1u: > > d35d4180 113126421 C Ii:1:002:3 0:8192 8 = 00001e00 00000000 > d35d4180 113126459 S Ii:1:002:3 -115:8192 8 < > d35d4180 130531486 C Ii:1:002:3 0:8192 8 = 00000000 00000000 > d35d4180 130531522 S Ii:1:002:3 -115:8192 8 < > > Windows SniffUSB summary: > > [369218 ms] <<< URB 13 coming back <<< 00000000: 00 00 1e 00 00 00 00 00 > [369218 ms] <<< URB 14 coming back <<< 00000000: 00 00 1e 00 00 00 00 00 > [369308 ms] <<< URB 15 coming back <<< 00000000: 00 00 00 00 00 00 00 00 You shouldn't trust the timestamps shown by USB sniffers under Windows too much. In many versions (if not all) their accuracy is limited to about 50 ms. Still, it should be good enough to distinguish between 270 ms and 90 ms. It's possible the device really does behave differently under Windows and Linux. You would have to compare all the interchanges to find the reason for this, however. > (UHCI) cat /proc/bus/usb/devices: > > T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=13d3 ProdID=3226 Rev= 2.00 > S: Manufacturer=Afatech > S: Product=DVB-T 2 > S: SerialNumber=010101010600001 > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA > I:* If#= 0 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=00 Prot=00 Driver=dvb_usb_af9015 > E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=84(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > E: Ad=85(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms > I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=01 Driver=usbhid > E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=16ms > > (EHCI) cat /proc/bus/usb/devices: > > T: Bus=01 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 2 Spd=480 MxCh= 0 > D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 > P: Vendor=13d3 ProdID=3226 Rev= 2.00 > S: Manufacturer=Afatech > S: Product=DVB-T 2 > S: SerialNumber=010101010600001 > C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA > I:* If#= 0 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=00 Prot=00 Driver=dvb_usb_af9015 > E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms > I:* If#= 1 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=01 Driver=usbhid > E: Ad=83(I) Atr=03(Int.) MxPS= 64 Ivl=4096ms That last value clearly indicates there is a bug in the device's firmware. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
