[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 #15 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to manauer.uel from comment #14)
> Something I did not notice before appears in both new logs: after the Cancel
> URB and Set TR Deq sequence completes, the ASMedia controller generates
> these:
> 
>     xhci_hcd 0000:0a:00.0: Spurious event dma 0x00000000012c50b0, comp_code
> 13 after 13
>     xhci_hcd 0000:0a:00.0: Spurious event dma 0x00000000012c50e0, comp_code
> 13 after 13
This may be valid HW behavior and sloppiness of the driver, if something is
submitting long and/or complex URBs, though I'm not sure what such URBs would
be doing on a bus with only hubs and HIDs. Or it may be a HW bug. Either way,
these pointers look like it comes from some other endpoint.

I could look at it out of curiosity, I think the simplest way is to
zip -r debugfs.zip /sys/kernel/debug/usb/xhci/0000:0a:00.0
shortly after it happens, should be enough if the bus isn't very busy.

Actually, if you upload this with the mouse recently connected and not working
we could inspect all those URBs and commands written to memory and check for
(or eliminate) most possible driver bugs. I suspect it's a HW bug.

> The wireless dongle itself also has Cancel URBs on ep 0x81 and ep 0x82
> during its own enumeration, but it recovers fine and no spurious events
> follow its cancellations. The wired mouse does not recover the same way.
Weird. I think the receiver has a different polling rate (1ms?). Do you have
more mice to check if it's a consistent pattern that things only work if at
least one 1ms device is connected, or something stupid like that?

Are you able to run a patched kernel? Lacking better ideas, I suppose we could
force 1ms polling and see what happens (don't bother with usbhid mousepoll
option - it doesn't work on xhci-hcd).

> Would it be possible to have a quirk that applies to a whole subset of
> devices (in this case mice), instead of one specific device only?
Maybe, but you suggest to disable a power saving feature everywhere for the
sake of one old questionable xHCI controller. Maybe there is a better way.

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

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