New: mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
https://bugzilla.kernel.org/show_bug.cgi?id=221318
Bug ID: 221318
Summary: mice behind ASMedia ASM1042A via Thunderbolt 2 never
produce input, most likely due to interrupt pipe idle window during enumeration
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: high
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: No
This is filed under drivers/usb because the problem involves the interaction between the usbhid driver, the USB host controller, and the Thunderbolt 2 bridge. The drivers/hid/usbhid subsystem is also directly involved, specifically the behavior of the interrupt pipe after enumeration. There is no drivers/thunderbolt component available to select, but the Thunderbolt 2 bridge appears to be a contributing factor as described below.
On a MacBook Pro 13" Early 2015 (MacBookPro12,1) with an LG UltraWide (34UC98, internal hub: ASMedia ASM1042A) monitor connected via Thunderbolt 2, USB mice connected through the monitor's built-in hub never produce any input. This happens consistently, whether the mouse is plugged in before boot or after. The mouse is fully enumerated, appears in lsusb, has a correct /dev/input/by-id/...-event-mouse node, and is recognized by libinput, but no motion or button events are produced.
# Affected hardware:
- Machine: MacBook Pro 13" Early 2015 (MacBookPro12,1)
- Monitor: LG UltraWide (34UC98), connected via Thunderbolt 2
- USB host controller: ASMedia ASM1042A, PCI ID 1b21:1142
- Affected: any USB mouse connected through the monitor hub
- Not affected: keyboards on the same hub, mice connected to the same monitor via USB instead of Thunderbolt 2
# Kernel versions tested:
Reproduces on Fedora 43 (6.17), and on a Rawhide kernel (7.0.0-0.rc4). Also reproduces on CachyOS, Ubuntu and Pop!_OS, so it is not distribution-specific.
# Theory on why this is happening:
After enumeration, the usbhid driver stops submitting interrupt URBs if no userspace application has opened the device yet. There is a brief idle window before the desktop environment opens /dev/hidrawX. The ASMedia TT appears to be sensitive to this idle condition when the hub is accessed through the Thunderbolt 2 bridge. Once the interrupt pipe goes quiet, the TT most likely stops delivering input silently and does not recover, even after userspace opens the device. The same hub connected via USB does not exhibit this behavior, pointing to the Thunderbolt 2 bridge as a contributing factor. Why the Thunderbolt 2 bridge makes the difference is not clear to me.
One additional observation worth mentioning: plugging in an unrelated Logitech wireless receiver into the monitor hub suddenly makes the wired mouse work (re-plugging needed). The receiver belongs to a completely different wireless mouse and has no logical connection to the wired mice. It prevents the problem, though why exactly is unclear. The additional USB traffic it puts on the controller might be the reason, but I am not sure.
Applying HID_QUIRK_ALWAYS_POLL via the kernel command line fixes the problem for a specific mouse: usbhid.quirks=0x046d:0xc049:0x00000400
This strongly suggests the problem is the interrupt pipe going idle. As a generic workaround, holding a file descriptor open on /dev/hidrawX via a udev rule has the same effect and works for any mouse without needing vendor and product IDs
Maybe consider keeping the interrupt pipe active by default for all HID mice until userspace opens the device, or automatically applying HID_QUIRK_ALWAYS_POLL for mice behind Thunderbolt bridges.
A workaround and write-up are available at:
https://github.com/NextBlaubeere/asmedia-usb-mouse-fix
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
https://bugzilla.kernel.org/show_bug.cgi?id=221318
Michał Pecio ([email protected]) changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]
--- Comment #1 from Michał Pecio ([email protected]) --- ASM1042A is a host controller, not a hub, but there is likely a hub between ASM1042A and the USB ports on the monitor. Maybe the same hub which shows up when the monitor is plugged into USB instead of Thunderbolt.
Could you post "lsusb -tv" for both connection variants with the same mouse in the same monitor port?
Maybe see if dynamic debug spits out something useful:
echo 'module xhci_hcd +p' >/proc/dynamic_debug/control dmesg -W >log.txt
Then connect the mouse with your udev rule, make a few clicks, disconnect, remove the udev rule, connect again, make a few clicks. Attach the resulting log.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #2 from [email protected] ---
Created attachment 309815
--> https://bugzilla.kernel.org/attachment.cgi?id=309815&action=edit
lsusb -tv with monitor connected via USB
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #3 from [email protected] ---
Created attachment 309816
--> https://bugzilla.kernel.org/attachment.cgi?id=309816&action=edit
lsusb -tv with monitor connected via Thunderbolt 2
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #4 from [email protected] ---
Created attachment 309817
--> https://bugzilla.kernel.org/attachment.cgi?id=309817&action=edit
dmesg -W with connection through Thunderbolt 2
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #5 from [email protected] ---
Created attachment 309818
--> https://bugzilla.kernel.org/attachment.cgi?id=309818&action=edit
dmesg -W with connection through USB
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #6 from [email protected] ---
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:
Quoted 2 lines
xhci_hcd0000:0a:00.0: Split transaction error for slot 3 ep 2xhci_hcd0000:0a:00.0: Hard-reset ep 2, slot 3
Shortly after, the mouse disconnects:
Quoted 1 line
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.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #7 from Michał Pecio ([email protected]) --- (In reply to manauer.uel from comment #6)
Quoted 3 lines
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
Unrelated, though a little odd. Can you check what's making this noise? cat /sys/kernel/debug/usb/xhci/0000:00:14.0/devices/02/name
Quoted 3 lines
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.
Same thing on the good bus. EP 0 stall is just some control request unsupported by the device. More interesting is interrupt endpoint 0x81 aka "ep 2".
But little happens here. The initial Stopped events on ep 2 and 4 are probably xhci_endpoint_reset(), then EP 0 stalls twice more and then usbhid cancels some URB from the interrupt endpoint.
Does this cancellation go away when you enable the udev rule or ALWAYS_POLL? Maybe something goes wrong here.
Then there is nothing, which means that URBs are completing successfully or not at all (as the mouse doesn't work, probably the latter). At some point disconnection and cancellation again, which proves that there was some URB on the endpoint at the time.
Quoted 6 lines
But then this appears:
Quoted 2 lines
xhci_hcd0000:0a:00.0: Split transaction error for slot 3 ep 2xhci_hcd0000:0a:00.0: Hard-reset ep 2, slot 3Shortly after, the mouse disconnects:
Quoted 1 line
usb 3-1.1: USB disconnect, device number 5
I/O errors aren't entirely uncommon when a device disconnects. Does it mean that the device kept disconnecting by itself and it wasn't you doing it?
Do you have some other USB 2.0/3.0 hub you could put between the monitor and the mouse? Does it make any difference?
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #8 from [email protected] ---
Created attachment 309827
--> https://bugzilla.kernel.org/attachment.cgi?id=309827&action=edit
dmesg -W with connection through Thunderbolt 2 udev-rule on only
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #9 from [email protected] ---
Quoted 2 lines
Can you check what's making this noise?
cat /sys/kernel/debug/usb/xhci/0000:00:14.0/devices/02/name
$ sudo cat /sys/kernel/debug/usb/xhci/0000:00:14.0/devices/02/name
2-3That 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.
$ lsusb | grep "Bus 002"
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 002 Device 002: ID 05ac:8406 Apple, Inc. Internal Memory Card Reader $ cat /sys/bus/usb/devices/2-3/manufacturer
Apple
$ cat /sys/bus/usb/devices/2-3/product
Card Reader
$ cat /sys/bus/usb/devices/2-3/idVendor
05ac
$ cat /sys/bus/usb/devices/2-3/idProduct
8406Quoted 2 lines
Does this cancellation go away when you enable the udev rule or
ALWAYS_POLL? Maybe something goes wrong here.
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.
Quoted 2 lines
Does it mean that the device kept disconnecting by itself and it wasn't you doing it?
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, if I remember it correctly:
Quoted 9 lines
Quoted 1 line
Then connect the mouse with your udev rule, make a few clicks, disconnect,
remove the udev rule, connect again, make a few clicks.
Do you have some other USB 2.0/3.0 hub you could put between the monitor and the mouse?
Does it make any difference?
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.
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. The dongle itself has nothing to do with the wired mouse. I have no good explanation for why a second device being present would change anything, but it seemed worth mentioning in case it points at something on the hub or controller side.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #10 from [email protected] ---
Correction to my previous comment:
I said I could not rule out that the device disconnected on its own. Looking at the new log more carefully, the mouse was already working with the rule active when I started capturing. When I manually unplugged it, a split transaction error appears right at the moment of disconnect. So that error is a consequence of pulling the cable.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #11 from Michał Pecio ([email protected]) --- (In reply to manauer.uel from comment #9)
Quoted 3 lines
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".
Quoted 7 lines
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.
Quoted 4 lines
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
Quoted 4 lines
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.
Quoted 3 lines
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?
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #12 from [email protected] ---
Created attachment 309832
--> https://bugzilla.kernel.org/attachment.cgi?id=309832&action=edit
dmesg -W with connection through Thunderbolt 2 udev-rule off only
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #13 from [email protected] ---
Created attachment 309833
--> https://bugzilla.kernel.org/attachment.cgi?id=309833&action=edit
dmesg -W with connection through Thunderbolt 2 dongle plugged in udev-rule off
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #14 from [email protected] ---
Quoted 4 lines
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?
It works despite the cancellation. The Cancel URB on ep 0x81 still happens with the dongle present, same as without it.
Note: I had to add a USB hub between the monitor and the mouse to have enough ports for the dongle, so the mouse now shows up as 3-1.1.4 instead of 3-1.1. The issue persists the same way through the hub. Current topology on the ASMedia controller:
/: Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
ID 043e:9a10 LG Electronics USA, Inc. 34UC88-B
|__ Port 001: Dev 005, If 0, Class=Hub, Driver=hub/5p, 480M
ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
|__ Port 001: Dev 006, If 0, Class=Human Interface Device,
Driver=usbhid, 12M
ID fffe:0005
|__ Port 001: Dev 006, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
ID fffe:0005
|__ Port 001: Dev 006, If 2, Class=Human Interface Device,
Driver=usbhid, 12M
ID fffe:0005
|__ Port 004: Dev 011, If 0, Class=Human Interface Device,Driver=usbhid, 12M
ID 046d:c049 Logitech, Inc. G5 Laser Mouse
|__ Port 004: Dev 011, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
ID 046d:c049 Logitech, Inc. G5 Laser Mouse
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 13after 13
This appears both when the mouse does not work (no rule, no dongle) and when it does work (dongle present). I do not know what to make of it, but it shows up in both cases and not in the log with the udev rule active.
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.
Quoted 2 lines
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 think I replugged it multiple times per test, which made the logs harder to read. I captured a cleaner second log without the udev rule and without the dongle to have a baseline. Both logs are attached if useful.
Quoted 3 lines
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.
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?
I am currently away for Easter break, but next weekend I will have access to a second LG monitor from the same era that shows the same issue. I will check whether it runs on the same controller.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #15 from Michał Pecio ([email protected]) --- (In reply to manauer.uel from comment #14)
Quoted 8 lines
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_code13 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.
Quoted 3 lines
The wireless dongle itself also has Cancel URBs on ep
0x81and ep0x82during 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).
Quoted 2 lines
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.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #16 from [email protected] ---
Created attachment 309839
--> https://bugzilla.kernel.org/attachment.cgi?id=309839&action=edit
ASMedia ASM1042A debugfs state, captured ~10s after connecting non-working Logitech G5 mouse
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #17 from [email protected] ---
Quoted 3 lines
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.
I attached the zip file. It was captured by connecting the mouse without the udev rule active and without the dongle, waiting about 10 seconds, then running your suggested command.
sudo zip -r debugfs.zip /sys/kernel/debug/usb/xhci/0000:0a:00.0
Quoted 3 lines
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?
This was a surprise. It turns out there are mice that work fine without any workaround. I swear, the four mice I originally tested were all Logitech plus one no-name mouse from my partner, and none of them worked, which is why this did not come up earlier.
Mouse Interfaces bInterval Works
Lenovo USB Optical (17ef:608d) 1 10ms yes
Microsoft Comfort 3000 (045e:077b) 1 10ms yes
Holtek MGK-15BU (04d9:1135) 1 10ms yes
Logitech G5 (046d:c049) 2 1ms/10ms no
Logitech G Pro Wireless (046d:c088) 3 1ms/1ms/1ms no (tested viacable)
Logitech G403 ? ? no (not at
hand)
Another no-name mouse (partner's) ? ? no (not at
hand)
The working mice all have a single interface. The failing mice all have multiple interfaces and at least one endpoint polling at 1ms. The G Pro Wireless was connected via cable for this test. Its wireless dongle (046d:c539) was not plugged in during any of these tests. That dongle is the same one that was observed earlier to make all other mice work when plugged in alongside them.
Quoted 3 lines
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).
Sure, I can try running a patched kernel if you think it is worth it, just for testing. I would not want to maintain a custom kernel long term, but a one-off build to confirm a fix is fine. Given the data above though, forcing 1ms might make things worse rather than better since 1ms seems to be what correlates with failure. Would forcing 10ms on the failing mice be a more interesting test?
Quoted 2 lines
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.
That is a fair point. If there is a more targeted fix, either in the ASM1042A handling or scoped to the controller rather than all mice, that would obviously be preferable. I am happy to test whatever approach you think makes more sense.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #18 from [email protected] ---
One addition to the mouse comparison table. I checked the Logitech Lightspeed Receiver, the wireless dongle that was observed earlier to make all other mice work when plugged in alongside them and the wired mouse re-plugged ...
Logitech Lightspeed Receiver (046d:c539) 3 1ms/1ms/1ms yes
It has 3 interfaces, all polling at 1ms, which is exactly the same profile as the failing mice. Yet it works on its own and somehow makes wired mice work alongside it. This unfortunately does not fit the pattern from the previous comment.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #19 from Michał Pecio ([email protected]) ---
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. The driver isn't very good at telling apart certain valid and invalid events, it just logs them all.
Mouse interrupt endpoint has an URB at 1267010, cycle bit 1 as expected.
0 0x0000000001267000: Buffer 0000000000000000 length 0 TD size 0 intr 0 type
'No-Op' flags b:i:i:c:s:i:e:C
0 0x0000000001267010: Buffer 000000000125e700 length 10 TD size 0 intr 0 type
'Normal' flags b:i:I:c:s:I:e:C
Cancellation commands, Set TR Dequeue to 1267010 with cycle 1.
0 0x0000000001201950: Stop Ring Command: slot 7 sp 0 ep 3 flags C 0 0x0000000001201960: Set TR Dequeue Pointer Command: deq 0000000001267011
stream 0 slot 7 ep 3 flags C
Their completion events have been overwritten by SuperSpeed device activity, but no sign of problems was seen in logs.
Endpoint is running so the doorbell has been rung after 1267010 submission. 0x000000000125d060: State running mult 1 max P. Streams 0 interval 1000 us max ESIT payload 10 CErr 3 Type Int IN burst 0 maxp 10 deq 0000000001267011 avg trb len 10, virt_state:0x0
I see nothing obviously wrong here, it looks like some weird HW problem.
BTW, I see that the endpoint of interest has 1ms interval too, longer interval is on the second endpoint of this mouse. IDK if it matters anyway.
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. Leave *8 unchanged.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #20 from [email protected] ---
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 2 lines
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.
Quoted 3 lines
If you would like to play with intervals, see
drivers/usb/host/xhci-mem.cfunctionxhci_parse_frame_interval(). Replaceep->desc.bIntervalwith 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.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
[Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
In reply to [email protected]https://bugzilla.kernel.org/show_bug.cgi?id=221318
--- Comment #21 from [email protected] ---
I just tested at a second location. Same MacBook Pro 13" Early 2015 and same ASMedia ASM1042A, but a different monitor (LG 34UC88-B instead of LG 34CB98-B) and a different mouse (Logitech G403 Prodigy, 046d:c083, two interfaces both at 1ms). Same issue, same workaround fixes it.
Bus 003.Port 001: Dev 001, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 001: Dev 002, If 0, Class=Hub, Driver=hub/4p, 480M
ID 043e:9a10 LG Electronics USA, Inc. 34UC88-B
|__ Port 003: Dev 003, If 0, Class=Hub, Driver=hub/4p, 480M
ID 2109:2813 VIA Labs, Inc. VL813 Hub
|__ Port 001: Dev 005, If 0, Class=Human Interface Device,Driver=usbhid, 12M
ID 046d:c083 Logitech, Inc. G403 Prodigy Gaming Mouse
|__ Port 001: Dev 005, If 1, Class=Human Interface Device,
Driver=usbhid, 12M
ID 046d:c083 Logitech, Inc. G403 Prodigy Gaming Mouse
Interface 0: bInterfaceProtocol Mouse, EP 0x81 IN, bInterval 1
Interface 1: bInterfaceProtocol 0, EP 0x82 IN, bInterval 1I also plugged in a no-name mouse (China Resource Semico, 1a2c:0043, one interface at 10ms) and it works fine without any workaround. Same controller, same hub chain. The 10ms vs 1ms pattern holds here too.
Interface 0: bInterfaceProtocol Mouse, EP 0x81 IN, bInterval 10
I also noticed that all mice work in the OpenCore bootloader, same as on macOS and Windows. OpenCore uses the EFI USB stack, which presumably keeps the interrupt pipe active without idle logic. This fits the theory that the problem is not necessarily in the ASM1042A hardware alone or in usbhid alone, but in the combination of those two.
Signature · 4 lines
You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.