On Tue, 21 Apr 2009, Stuart wrote: > 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? No, it is an artifact of ehci-hcd. The driver is unable to schedule any periodic transfers at intervals beyond 1024 ms, so anything longer than that gets rounded down. > 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? I don't know anything about the device's firmware; you'll probably have to complain to the manufacturer and ask them to fix it. Both the 17x behavior and the incorrect bInterval value. Yes, you certainly can add a special HID driver for this device. But fixing the firmware would be preferable. > > 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? I meant all the USB transfers. Just look at the logs from the Windows sniffer and from usbmon, and see what the two systems do differently. Maybe Windows ignores the value in the descriptor and polls at intervals of 1 ms; then the 17x behavior might still be present but it would be undetectable. > > > (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.) Yes, that's exactly what I mean. It seems obvious that a polling interval of 4 seconds has to be wrong. 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
