public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@kernel.org
To: linux-usb@vger.kernel.org
Subject: [Bug 221318] mice behind ASMedia ASM1042A via Thunderbolt 2 never produce input, most likely due to interrupt pipe idle window during enumeration
Date: Sun, 05 Apr 2026 22:37:31 +0000	[thread overview]
Message-ID: <bug-221318-208809-2JNibxA1vg@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-221318-208809@https.bugzilla.kernel.org/>

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.

  parent reply	other threads:[~2026-04-05 22:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-03 20:22 [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
2026-04-04  9:54 ` [Bug 221318] " bugzilla-daemon
2026-04-04 17:32 ` bugzilla-daemon
2026-04-04 17:33 ` bugzilla-daemon
2026-04-04 17:34 ` bugzilla-daemon
2026-04-04 17:35 ` bugzilla-daemon
2026-04-04 17:39 ` bugzilla-daemon
2026-04-04 21:02 ` bugzilla-daemon
2026-04-05 22:09 ` bugzilla-daemon
2026-04-05 22:37 ` bugzilla-daemon [this message]
2026-04-05 22:44 ` bugzilla-daemon
2026-04-06  8:30 ` bugzilla-daemon
2026-04-06 11:35 ` bugzilla-daemon
2026-04-06 11:36 ` bugzilla-daemon
2026-04-06 11:54 ` bugzilla-daemon
2026-04-06 15:35 ` bugzilla-daemon
2026-04-06 19:56 ` bugzilla-daemon
2026-04-06 20:06 ` bugzilla-daemon
2026-04-06 20:11 ` bugzilla-daemon
2026-04-07  7:13 ` bugzilla-daemon
2026-04-07 13:18 ` bugzilla-daemon
2026-04-09 22:29 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-221318-208809-2JNibxA1vg@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox