[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 #11 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to manauer.uel from comment #9)
> That would be bus 2, port 3 on the Intel controller, right? Checking sysfs
> says it is the Apple Internal Memory Card Reader (05ac:8406), the SD card
> slot built into the MacBook.
Right. Not sure what's happening here, but "rmmod usb-storage" would silence
it. But not a big deal, I filtered your logs with "grep -v 0000:00:14".

> I captured a new log with the rule enabled and replugged the mouse. I think
> with the udev rule active the cancellation disappears as far as I can see.
> The enumeration looks the same as before up to the point where the mouse is
> recognized and the hidraw nodes are created. After that, the ASMedia
> controller goes completely silent. No Cancel URB on ep 0x81, no split
> transaction error, nothing. Just the Intel slot 2 ep 2 stalls in the
> background as usual. The mouse works.
Yep. I tried the quirk here and it eliminates the cancellation. Without the
quirk it happens when udev briefly opens and closes the mouse before the GUI
does. The kernel can't do much about it, besides the quirk.

I failed to reproduce this bug on two ASM1042 (non-A) controllers I have. The
URB is canceled and later a new one is submitted and the mouse works.

> Some were definitely me replugging. But I cannot rule out that the device
> also disconnected on its own at some point before I pulled the cable. The
> split transaction error appeared very shortly before one of the disconnects,
> so it is possible both happened. I definitely followed your instruction
Yes, I asked to try with and without workarounds, but the log shows multiple
disconnections so I wasn't sure what's going on.

I suspect that Split Transaction Error on disconnection is seen when the mouse
works and not seen when it doesn't work. Because it looks like the next URB
submitted after cancellation is somehow ignored by the HC.

But I see nothing wrong here:
# usbhid unlinks its URB
[  393.432235] xhci_hcd 0000:0a:00.0: Cancel URB 00000000ea33d4b2, dev 1.1, ep
0x81, starting at offset 0x1284000
# Stop Endpoint is queued (as it should) and succeeds on first try
[  393.432243] xhci_hcd 0000:0a:00.0: // Ding dong!
[  393.432340] xhci_hcd 0000:0a:00.0: Stopped on Transfer TRB for slot 3 ep 2
# Set TR Deq target pointer and cycle look right
[  393.432700] xhci_hcd 0000:0a:00.0: Removing canceled TD starting at
0x1284000 (dma) in stream 0 URB 00000000ea33d4b2
[  393.432706] xhci_hcd 0000:0a:00.0: Set TR Deq ptr 0x1284010, cycle 1
[  393.432708] xhci_hcd 0000:0a:00.0: // Ding dong!
[  393.432713] xhci_hcd 0000:0a:00.0: xhci_giveback_invalidated_tds: Keep
cancelled URB 00000000ea33d4b2 TD as cancel_status is 2
# and it completes successfully
[  393.432864] xhci_hcd 0000:0a:00.0: Successful Set TR Deq Ptr cmd, deq =
@01284010
[  393.432875] xhci_hcd 0000:0a:00.0: xhci_handle_cmd_set_deq: Giveback
cancelled URB 00000000ea33d4b2 TD
[  393.432877] xhci_hcd 0000:0a:00.0: Giveback URB 00000000ea33d4b2, len = 0,
expected = 10, status = -115
# the doorbell likely isn't rung due to no URBs, it shouldn't matter anyway
[  393.432881] xhci_hcd 0000:0a:00.0: xhci_handle_cmd_set_deq: All TDs cleared,
ring doorbell

> I already tried this with two different USB hub dongles placed between the
> monitor and the mouse. The behavior was identical. The problem persists
> regardless of which hub is in between, which made me think the issue is
> maybe with the ASMedia controller itself rather than the LG hub specifically.
Yes indeed, it's exactly why I thought about checking this.

> One observation that might or might not be related I already mentioned in my
> initial report is that plugging in an unrelated wireless Logitech USB dongle
> into the monitor makes the wired mouse start working after replugging.
Bizarre. Does it prevent the cancellation, or does it work despite it?

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

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