[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=221318

--- Comment #20 from manauer.uel@gmail.com ---
> The "spurious event" noise is likely from SuperSpeed device 4-1.1.2 whose
> Bulk IN URBs may trigger it even on properly working hardware.
Good to know. I looked up 4-1.1.2, it turned out to be the Ethernet adapter
from the USB dongle.

> I see nothing obviously wrong here, it looks like some weird HW problem.
The sequence looks correct on paper, the cancellation goes through cleanly and
the endpoint is left in running state with the dequeue pointer advanced past
the old URB. Yet no new transfer ever arrives.

> BTW, I see that the endpoint of interest has 1ms interval too, longer
> interval is on the second endpoint of this mouse.
Yes, that matches the lsusb output.

> If you would like to play with intervals, see drivers/usb/host/xhci-mem.c
> function xhci_parse_frame_interval(). Replace ep->desc.bInterval with any
> number like 1 or 10, units are milliseconds.
I built and tested two patched kernels.

Forcing 10ms: the mouse works without any workaround at all.
Forcing 1ms: the mouse does not work. The udev workaround still fixes it.

So the interval does matter. With 10ms the problem does not occur in the first
place, with 1ms it behaves the same as on the stock kernel.

One thing that does not fit this pattern: the Logitech Lightspeed Receiver
(046d:c539) has 3 interfaces all polling at 1ms, yet it works on its own
without any workaround. It also makes wired mice work alongside it on the stock
kernel.

I looked into this a bit. The receiver is not handled by usbhid but by the
logitech-djreceiver driver (hid-logitech-dj). That driver has its own
hid_ll_driver with open and close callbacks that are essentially empty. When
udev opens and closes the hidraw device, nothing happens at the USB level, so
no URB is cancelled. This might be why the ASM1042A never gets into the broken
state.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.