Opened 13 years ago
Last modified 6 years ago
#8183 new bug
Intel 3400 USB errors
Reported by: | romain | Owned by: | mmlr |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Drivers/USB/EHCI | Version: | R1/alpha3 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
When plugging a microsoft explorer 4500 mouse, I have usb errors and the mouse does not work. USB works well for mass storage and keyboard. I have another mouse model that works also.
The usb reports of this model seems to be uncorrect: http://google.com/codesearch#fgLeHA0uieM/drivers/hid/hid-microsoft.c&q=microsoft%204500%20quirk%20lang:%5Ec$&type=cs
I do not know if this can be the source of the issue. The problems seems to be different than #5551 (controller and symptoms are different). Enclosed are syslogs with usb_hid and echi logs.
Attachments (2)
Change History (4)
by , 13 years ago
Attachment: | syslog.error added |
---|
by , 13 years ago
comment:1 by , 13 years ago
comment:2 by , 6 years ago
Component: | Drivers/USB → Drivers/USB/EHCI |
---|
Note:
See TracTickets
for help on using tickets.
OK, the bug that no error would get returned at all is fixed in hrev43408. The underlaying problem is not fixed by that however. The full-/lowspeed device attached (the mouse) fails the transfers. Most likely this happens due to missing support for frame span traversal nodes (FSTNs) which makes us always poll full-/lowspeed periodic transfers at a 1ms interval. Without FSTNs (and they are a bit of a mess to implement, really a workaround for a design problem IMHO) it's not possible to support the actually correct interrupt polling interval. Some (most?) devices simply don't return any new data or simply always return whatever data is buffered and don't actually care about the interval. But other devices may choke (rightfully) when they are polled at a too high frequency (at a rate faster than the one advertised in the endpoint descriptor). It is possible that the device at hand is such a device and won't work via a transaction translator until FSTN support is added.
Unfortunately you don't have any companion host controllers on your setup (instead there is a builtin hub/transaction translator in your enhanced host controller), which means that you don't have the option to simply plug the device into a root port to get it working. Since this kind of setup becomes more and more common, adding FSTN support is becoming more important...