[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 #6 from manauer.uel@gmail.com ---
Thanks for the hint! You are right, the ASM1042A is the host controller. The
actual hub inside the monitor is 043e:9a10 I think, and it shows up in both
connection variants. The difference is just which xHCI controller ends up
hosting it.


The Thunderbolt log contains two controllers: Intel (0000:00:14.0) and ASMedia
(0000:0a:00.0). The Intel slot 2 ep 2 stalls that repeat every two seconds or
so throughout the log are from a different device (i think) and are not related
to the mouse. The same stall pattern appears in the USB-only log as well.

The ASMedia side is where things go wrong. During each enumeration attempt of
the mouse (slot 3), ep 0 stalls repeatedly while the device is being
configured. That part eventually completes and the mouse is recognized. But
then this appears:
> xhci_hcd 0000:0a:00.0: Split transaction error for slot 3 ep 2
> xhci_hcd 0000:0a:00.0: Hard-reset ep 2, slot 3

Shortly after, the mouse disconnects:
> usb 3-1.1: USB disconnect, device number 5

It then re-enumerates, and the same cycle starts over.

The split transaction error message is maybe the thing we are hunting for,
since split transactions are the mechanism the hubs Transaction Translator uses
to bridge full-speed traffic to the high-speed controller, right?. I do not
know enough about xhci_hcd to say whether this means the TT itself is failing
or whether the ASMedia controller is mishandling the response. But it seems
worth looking at.

For completeness, the USB log shows no disconnect or split transaction errors
for the mouse. The stalls on slot 2 ep 2 that are present in that log are the
same unrelated device I think.

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

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