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