Opened 8 years ago

Last modified 10 months 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:
Has a Patch: no 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)

syslog.error (286.9 KB ) - added by romain 8 years ago.
syslog.ms (190.9 KB ) - added by romain 8 years ago.

Download all attachments as: .zip

Change History (4)

by romain, 8 years ago

Attachment: syslog.error added

by romain, 8 years ago

Attachment: syslog.ms added

comment:1 by mmlr, 8 years ago

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...

comment:2 by waddlesplash, 10 months ago

Component: Drivers/USBDrivers/USB/EHCI
Note: See TracTickets for help on using tickets.