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

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

[bugzilla-daemon]

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: drivers_usb@kernel-bugs.kernel.org
          Reporter: manauer.uel@gmail.com
        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

-- 
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

[bugzilla-daemon]

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

Michał Pecio (michal.pecio@gmail.com) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |michal.pecio@gmail.com

--- Comment #1 from Michał Pecio (michal.pecio@gmail.com) ---
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.

-- 
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

[bugzilla-daemon]

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

--- Comment #2 from manauer.uel@gmail.com ---
Created attachment 309815
  --> https://bugzilla.kernel.org/attachment.cgi?id=309815&action=edit
lsusb -tv with monitor connected via USB

-- 
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

[bugzilla-daemon]

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

--- Comment #3 from manauer.uel@gmail.com ---
Created attachment 309816
  --> https://bugzilla.kernel.org/attachment.cgi?id=309816&action=edit
lsusb -tv with monitor connected via Thunderbolt 2

-- 
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

[bugzilla-daemon]

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

--- Comment #4 from manauer.uel@gmail.com ---
Created attachment 309817
  --> https://bugzilla.kernel.org/attachment.cgi?id=309817&action=edit
dmesg -W with connection through Thunderbolt 2

-- 
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

[bugzilla-daemon]

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

--- Comment #5 from manauer.uel@gmail.com ---
Created attachment 309818
  --> https://bugzilla.kernel.org/attachment.cgi?id=309818&action=edit
dmesg -W with connection through USB

-- 
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

[bugzilla-daemon]

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.

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

[bugzilla-daemon]

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

--- Comment #7 from Michał Pecio (michal.pecio@gmail.com) ---
(In reply to manauer.uel from comment #6)
> 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

> 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.

> 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
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?

-- 
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

[bugzilla-daemon]

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

--- Comment #8 from manauer.uel@gmail.com ---
Created attachment 309827
  --> https://bugzilla.kernel.org/attachment.cgi?id=309827&action=edit
dmesg -W with connection through Thunderbolt 2 udev-rule on only

-- 
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

[bugzilla-daemon]

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

--- Comment #9 from manauer.uel@gmail.com ---
> 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-3

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.

    $ 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
    8406




> 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.




> 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:
> > 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.

-- 
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

[bugzilla-daemon]

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

--- Comment #10 from manauer.uel@gmail.com ---
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.

-- 
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

[bugzilla-daemon]

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.

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

[bugzilla-daemon]

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

--- Comment #12 from manauer.uel@gmail.com ---
Created attachment 309832
  --> https://bugzilla.kernel.org/attachment.cgi?id=309832&action=edit
dmesg -W with connection through Thunderbolt 2 udev-rule off only

-- 
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

[bugzilla-daemon]

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

--- Comment #13 from manauer.uel@gmail.com ---
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

-- 
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

[bugzilla-daemon]

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

--- Comment #14 from manauer.uel@gmail.com ---
> 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 13
after 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.

> 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.

> 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.

-- 
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

[bugzilla-daemon]

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.

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

[bugzilla-daemon]

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

--- Comment #16 from manauer.uel@gmail.com ---
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

-- 
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

[bugzilla-daemon]

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

--- Comment #17 from manauer.uel@gmail.com ---
> 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

> 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 via
cable)
    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.


> 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?


> 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.

-- 
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

[bugzilla-daemon]

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

--- Comment #18 from manauer.uel@gmail.com ---
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.

-- 
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

[bugzilla-daemon]

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

--- Comment #19 from Michał Pecio (michal.pecio@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. 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.

-- 
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

[bugzilla-daemon]

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.

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

[bugzilla-daemon]

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

--- Comment #21 from manauer.uel@gmail.com ---
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 1



I 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.

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

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