Hi Alan, Thanks for such a fast reply! > Which version of the Linux kernel are you using? I knew I'd forget something obvious, 2.6.29. > > 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. Where would the difference (/proc/bus/usb/devices 4096ms vs usbmon 8192 uframes/1024ms) come from? Would this also be a problem in the device firmware? > 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. In trying to work out what was going on some time ago I tried modifying the bInterval fixup in drivers/usb/core/config.c which didn't seem to work. I tried modifying hid_probe in drivers/usb/hid/usbhid/hid-core.c last night and again it didn't seem to work. However, this morning I was able to see a difference after a reboot (as opposed to just removing and inserting the various hid/usbhid related modules). I believe your conclusion that it's at least partially a firmware problem seems correct (and most likely entirely a firmware issue). I've tried using 4 different firmware versions both with and without a modified usbhid driver (setting bInterval to 8 in hid_probe). The latest version is 4.95.0. I've been using this version in both Windows and Linux for the usb sniffs and usbmon traces. This firmware version seems to add a strange 17x delay with Linux (accounting for the UHCI 272ms vs 16ms and EHCI 17.405s vs 1.024s). This version also gives additional key presses under Linux and Windows (they show up as additional interrupt transfers in usbmon, not as actual key press events). The previous 3 firmware versions (4.65.0, 4.71.0 and 4.73.0) didn't seem to show the 17x delay behaviour. Testing with version 4.65.0 and only worrying about EHCI showed a delay of 1024ms from usbmon with bInterval = 16 and 16ms with bInterval = 8 which seems more consistent with what would be expected. So, my next question is if there's any way for me to reverse the firmware to fix the real problem and if not is there a way to fix the bInterval value for this device? Possibly something like the various hid drivers such as hid-lg.c for hid quirks? > 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. It may be irrelevant now, but what do you mean by interchanges and how would I compare them? > > (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. I'm curious as to exactly what you mean here, from the spec I believe 16 is a valid number for a device of any speed, are you saying that the device should set bInterval to 16 for low/full speed and 8 for high speed to get a time interval of 16ms for both? (Maybe not 16ms specifically, but it should account for bus speed and keep the time interval constant rather than the value of bInterval.) Thanks again for your help, Stuart -- 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
