New: ASUS Zenbook S 14 UX5406SA: Unstable USB connection on USB-A port under certain condition

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

Bug ID: 219681
Summary: ASUS Zenbook S 14 UX5406SA: Unstable USB connection on
USB-A port under certain condition
Product: Drivers
Version: 2.5
Hardware: Intel
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: No

Created attachment 307476
--> https://bugzilla.kernel.org/attachment.cgi?id=307476&action=edit
dmesg output

Kernel version: 6.13.0-rc6-1-mainline
Kernel config:
https://github.com/archlinuxcn/repo/blob/d92ecf4073f4bb620665c2cd47b088efff31d43a/archlinuxcn/linux-mainline/config

Why this bug report:
No connection issues found under Windows.

USB devices affected:
* JMS583 disk enclosure
* 2 RTL8156B Ethernet adapter from different makers

USB devices unaffected:
* RTL9210B/ASM2464 disk enclosure (with the same disk)
* Any devices mentioned before, but connected to USB-C port through a passive USB-C to USB-A adapter

Steps to reproduce:
1. start the appropriate background service (NetworkManager and udisks2)
2. connect the device to the USB-A port
3. attempt to use the device, such as reading from the disk or letting NetworkManager to do some DHCP

Expected behavior:
No connection issue, just like how it works on USB-C port.

Actual behavior:
1. I/O timeout on the JMS583 disk enclosure (dmesg attached):

    # dd if=/dev/sda of=/dev/null bs=512 count=1 
    dd: error reading '/dev/sda': Input/output error
    0+0 records in
    0+0 records out
    0 bytes copied, 61.3496 s, 0.0 kB/s
2. frequent device reset on RTL8156B adapters (dmesg attached)

Attempts with a bus-powered USB hub connected to the USB-A port:
* connect ONE of such devices to the hub - same issues
* connect TWO of such devices to the hub - no issue on both devices

Additional information:
* Without udisks2 running, the JMS583 disk enclosure seems to work fine (no errors on simple dd commands)
* Without Ethernet cable connected, the RTL8156B adapter also seems to "work" fine

You may reply to this email to add a comment.

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

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

Michał Pecio ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Michał Pecio ([email protected]) --- Are the working and not working ports on the same USB bus, or on different ones? Perhaps two different types of USB controllers?

You can see the mapping between USB buses and PCI controllers with ls -l /sys/bus/usb/devices/usb*

udisks2 collects SMART data and this is known to cause problems with some combinations of USB controllers and disk enclosures in UAS mode. It usually recovers after the reset, so not sure why

[  131.357007] sd 0:0:0:0: Device offlined - not ready after error recovery

The network issue is possibly unrelated, because in this case the hub simply reports complete disconnection of the device and it comes back a moment later for unclear reasons.

I wonder if any of that is preceded by low level USB errors? Maybe try again with some dynamic debug:
echo 'func handle_tx_event +p' >/proc/dynamic_debug/control
echo 'func handle_transferless_tx_event +p' >/proc/dynamic_debug/control

I presume this is not a regression and there are no kernel versions where it works correctly?

You may reply to this email to add a comment.

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

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

--- Comment #2 from [email protected] ---

They are on different controllers:

    # readlink /sys/bus/usb/devices/usb*
    ../../../devices/pci0000:00/0000:00:0d.0/usb1
    ../../../devices/pci0000:00/0000:00:0d.0/usb2
    ../../../devices/pci0000:00/0000:00:14.0/usb3
    ../../../devices/pci0000:00/0000:00:14.0/usb4
    # lspci
    ...
    00:0d.0 USB controller: Intel Corporation Lunar Lake-M Thunderbolt 4 USB
Controller (rev 10)
    ...
    00:14.0 USB controller: Intel Corporation Lunar Lake-M USB 3.2 Gen 2x1 xHCI
Host Controller (rev 10)
    ...

It do have some messages like "Stopped on Transfer TRB for slot 4 ep 6" and "Transfer error for slot 9 ep 0 on endpoint"

This is a relatively new platform and kernels before 6.12 cannot give a usable system.

You may reply to this email to add a comment.

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

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

--- Comment #3 from [email protected] ---
Created attachment 307487
--> https://bugzilla.kernel.org/attachment.cgi?id=307487&action=edit
dmesg with dynamic debug

You may reply to this email to add a comment.

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

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

--- Comment #4 from Michał Pecio ([email protected]) --- Stopping is not suspicious, but "transfer errors" are. And disconnections seem to reliably happen 270ms later.

Not sure why, the driver should issue a retry and then either get another error or things should go back to normal.

What happens to the errors when it works (on USB-C or through a hub)? Are they still there but recovered from? Or not happening at all?

You may reply to this email to add a comment.

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

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

--- Comment #5 from [email protected] ---

Not happening at all on USB-C port.

As for the hub case, with the network adapter as the only device on hub, transfer errors are still there and the entire hub appears disconnected after it, but no more errors after another adapter (with same chip) comes to the hub.

You may reply to this email to add a comment.

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

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

Mathias Nyman ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected]
                   |                            |om

--- Comment #6 from Mathias Nyman ([email protected]) --- Could you share both dynamic debug and trace of this case?
If possible remove as all extra usb devices before triggering this, as logs gets clogged and hard to read.

mount -t debugfs none /sys/kernel/debug
echo 'module xhci_hcd =p' >/sys/kernel/debug/dynamic_debug/control echo 'module usbcore =p' >/sys/kernel/debug/dynamic_debug/control echo 81920 > /sys/kernel/debug/tracing/buffer_size_kb echo 1 > /sys/kernel/debug/tracing/events/xhci-hcd/enable echo 1 > /sys/kernel/debug/tracing/tracing_on
< Reproduce issue, connect problematic device >
Send output of dmesg
Send content of /sys/kernel/debug/tracing/trace

I'll try to find reproduce this on our local Lunar Lake one I get my hands on some failing devices, my current USB3 ethernet adapter unfortunately has a ASIX chip, not Realtek.

You may reply to this email to add a comment.

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

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

--- Comment #7 from [email protected] ---
Created attachment 307509
--> https://bugzilla.kernel.org/attachment.cgi?id=307509&action=edit
dmesg with more dynamic debug

You may reply to this email to add a comment.

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

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

--- Comment #8 from [email protected] ---
Created attachment 307510
--> https://bugzilla.kernel.org/attachment.cgi?id=307510&action=edit
trace

You may reply to this email to add a comment.

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

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

--- Comment #9 from Mathias Nyman ([email protected]) --- Thank you,

dmesg shows USB link goes to Inactive error state, and device needs to be reset to recover, hence the disconnect

The USB Link Power Management (LPM) U1 and U2 states, and Max exit latency (MEL) values look suspicious in the logs. An issue with these could cause link error.

Does disabling LPM for the Realtek usb network adapter help?

This can be done by adding USB_QUIRK_NO_LPM quirk "k" for your device vid:pid i.e. add "usbcore.quirks=0bda:8156:k" parameter to your kernel cmdline.

optionally remove xhci LPM support for Intel hosts and recompile kernel:

index 2d1e205c14c6..57a6641fbcef 100644
@@ -316,7 +316,7 @@ static void xhci_pci_quirks(struct device *dev, struct

xhci_hcd *xhci)

                xhci->quirks |= XHCI_BROKEN_D3COLD_S2I;

        if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
-               xhci->quirks |= XHCI_LPM_SUPPORT;
+//             xhci->quirks |= XHCI_LPM_SUPPORT;
                xhci->quirks |= XHCI_INTEL_HOST;
                xhci->quirks |= XHCI_AVOID_BEI;
        }

You may reply to this email to add a comment.

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

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

--- Comment #10 from [email protected] ---
Both kernel parameter and kernel patch can help the Ethernet adapter. It transferred tens of gigabytes without disconnecting.

No luck for the disk enclosure, but just found it also won't work on USB-C ports (at this time) and another AMD system, yet still no issue on a hub with multiple devices.

You may reply to this email to add a comment.

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

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

--- Comment #11 from Michał Pecio ([email protected]) --- OK, so the UAS bug is on three different host controllers now. It's strange that the hub still makes a difference. Stupid question: is the enclosure running at SuperSpeed when it works correctly?

Can you trigger the issue instantly without udisks2 by running something like 'skdump', 'smartctl -a' or 'smartctl -x'? This may be a more reliable reproducer than starting udisks2 and waiting, if the problem is caused by SMART queries.

There is this patch from Raspberry Pi which you could try. It should be harmless and some Realtek chip was supposedly caught having bugs in this area, but I tried it on a different buggy UAS chip and it didn't help so YMMV.
https://github.com/raspberrypi/linux/commit/66aef6ce3557edd9d58d794e4a800c5be49ca0e7

You may reply to this email to add a comment.

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

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

--- Comment #12 from [email protected] ---

There are some chances to work with SuperSpeed+, mostly with a longer cable.

To manually trigger the issue without udisks2:

echo "write through" > /sys/class/scsi_disk/0:0:0:0/cache_type smartctl -a /dev/sda
dd if=/dev/sda of=/dev/null count=1

But this sequence more often gives ~30s IO delay, not timeout.

Also tried another disk with this enclosure and the issue is gone. Seems the disk is to blame.

As for the Realtek ethernet, I found it never enters U1/U2 state on Windows. Given there is already NO_LPM quirks for RTL8153, maybe we also need one for RTL8156?

You may reply to this email to add a comment.

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

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

MasterCATZ ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #13 from MasterCATZ ([email protected]) --- not entirely the same issue

but I can no longer reload xhci_hcd because its now built into the kernel

6.12.3-061203-generic

sudo modprobe -r xhci_hcd
modprobe: FATAL: Module xhci_hcd is builtin

how can I now restart it ?
and who the heck thought building in a xhci_hcd module was a good idea ? lose usb you loose keyboard / mouse = bricked system unless you can ssh in with a phone ..

https://ibb.co/c8YFYhG

even if I hibernate and do a full power off and resume when OS loads USB is dead again (works in bios etc just OS loads it up dead )

You may reply to this email to add a comment.

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

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

--- Comment #14 from Michał Pecio ([email protected]) ---

Your distribution did, it's their choice.

This should be posted as a separate bug, not here.

You may reply to this email to add a comment.

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

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

--- Comment #15 from Michał Pecio ([email protected]) --- (In reply to dantmnf2 from comment #12)

What I was thinking is if there is any chance that the hub limits it to hi-speed, this could explain how some hardware bugs miraculously go away.

There seem to be issues with some combinations of disks and enclosures, but I have never looked into it. It sounds more like a storage problem than a USB problem to me. At this point I think your best bet would be to read Documentation/admin-guide/reporting-issues.rst and mail linux-usb and linux-scsi about this specific UAS issue, because few developers really follow this bugzilla.

You may reply to this email to add a comment.

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