Which Linux distro are you using? Slackware64-current
Which release version? Rolling / custom
Which kernel are you using? 7.0.0-rc1 (also tested on 6.12.67, same behavior)
Which BIOS version are you using? 03.05 (10/30/2025)
Which Framework Laptop 13 model are you using? AMD Ryzen AI 300 Series
Summary
I’m seeing intermittent USB3 hub disconnects through my USB-C dock roughly 2-3 times per day during normal active use. The USB3 path drops and re-enumerates, but the USB4 tunnel itself survives — the display stays up and only the USB3 devices (ethernet NIC, USB peripherals) cycle. Networking recovers automatically after re-enumeration.
There are no preceding driver errors in dmesg before the disconnect — the hub just drops cleanly.
I wanted to post this here before filing a kernel bug since @Mario_Limonciello has been active on USB4/thunderbolt issues for this platform and might have insight into whether this is a known issue or if there are patches in flight that address it.
Hardware
-
Framework 13 AMD Ryzen AI 300 Series
-
UGREEN Revodok Pro 314 (14-in-1 USB-C dock, VIA Labs USB3 hub controllers, Realtek RTL8153 gigabit NIC)
-
External display: Dell UP3017 (2560x1600) via dock HDMI
-
Dock connected to left rear USB-C port
USB4 Controller Info
c3:00.5 USB controller: AMD USB4 Router 0 (prog-if 40 [USB4 Host Interface])
Kernel driver in use: thunderbolt (builtin)
c3:00.6 USB controller: AMD USB4 Router 1 (prog-if 40 [USB4 Host Interface])
Kernel driver in use: thunderbolt (builtin)
Both domains report user security. No NVM version exposed.
What Happens
Roughly every 3-4 hours during active use, the USB3 hub inside the dock disconnects and the dock-level USB device resets. Here is a typical dmesg sequence:
[Feb28 18:10] usb 6-1.2: USB disconnect, device number 5
[ +0.000007] r8152-cfgselector 6-1.2.3: USB disconnect, device number 6
[ +0.265946] usb 6-1: reset SuperSpeed Plus Gen 2x1 USB device number 2 using xhci_hcd
[ +0.692308] usb 6-1.2: new SuperSpeed USB device number 7 using xhci_hcd
[ +0.039389] usb 6-1.2: New USB device found, idVendor=2109, idProduct=0817, bcdDevice= 1.d4
[ +0.000009] usb 6-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ +0.000003] usb 6-1.2: Product: USB3.0 Hub
[ +0.000002] usb 6-1.2: Manufacturer: VIA Labs, Inc.
[ +0.019999] hub 6-1.2:1.0: USB hub found
[ +0.000184] hub 6-1.2:1.0: 4 ports detected
[ +0.627256] usb 6-1.2.3: new SuperSpeed USB device number 8 using xhci_hcd
[ +0.011473] usb 6-1.2.3: New USB device found, idVendor=0bda, idProduct=8153, bcdDevice=31.fd
[ +0.113156] r8152-cfgselector 6-1.2.3: reset SuperSpeed USB device number 8 using xhci_hcd
[ +0.106424] r8152 6-1.2.3:1.0 eth95: renamed from eth0
[ +0.000190] r8152 6-1.2.3:1.0 eth2: renamed from eth95
[ +3.768210] r8152 6-1.2.3:1.0 eth2: carrier on
Key observations:
-
No r8152 Tx errors or any other errors precede the disconnect — it just drops
-
The dock-level device (
usb 6-1) resets, not just the hub -
The display path (bus 5) is unaffected — only bus 6 (USB3) drops
-
The NIC and other USB devices re-enumerate and recover on their own
-
Ethernet comes back with a working link within a few seconds
-
This happens regardless of traffic load on the ethernet interface
-
Tested with two UGREEN docks (same model) — identical behavior on both, so it’s not a defective unit
Related Issue (Resolved)
I also had a separate issue where the entire USB4 tunnel would collapse (both bus 5 and bus 6, display included) triggered by DPMS power off via wlopm. I worked around this by using wlr-randr --output --off instead of kernel DPMS, which removes the output at the compositor level without touching the DPMS path. The full tunnel collapses stopped after this change. The intermittent USB3 hub disconnects described above are a separate issue that persists.
What I’ve Already Tried
-
Disabled PCIe ASPM (
pcie_aspm=offon kernel cmdline) — no change -
Disabled USB autosuspend for the NIC and hub via udev rules — no change
-
Disabled GRO on the ethernet interface — no change
-
Unplugged ethernet from dock entirely — hub drops still occur (less frequently, but still happen)
-
Tested on kernel 6.12.67 — same behavior
-
Verified dock is not defective (tested with two identical units)
Questions
-
Is this a known issue with the AMD USB4/thunderbolt stack on Strix Point? The hub drops are clean (no preceding errors) which makes me wonder if this is a link-level issue in the USB4 tunnel’s USB3 path rather than anything the dock or NIC is doing wrong.
-
I saw the recent commit
58d71d4242ce(“thunderbolt: Fix wake on connect at runtime”) — could runtime wake-on-connect behavior be related to these intermittent drops? -
Are there any other thunderbolt/USB4 patches in flight for Strix Point that might address tunnel stability?
-
Is there anything else I can capture to help debug this? Happy to run with extra tracing enabled or test patches.
System Details
$ uname -a
Linux localhost 7.0.0-rc1-20260222.1500PST #6 SMP PREEMPT_DYNAMIC Sun Feb 22 15:18:45 PST 2026 x86_64 AMD Ryzen AI 9 HX 370 w/ Radeon 890M AuthenticAMD GNU/Linux
$ lsusb -t (dock portion)
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 20000M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 10000M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 5000M
|__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 10000M (VIA Labs 2109:0817)
|__ Port 3: Dev 4, If 0, Class=Vendor Specific Class, Driver=r8152, 5000M (RTL8153)
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
(USB2 side — HID devices, audio, etc.)
$ lspci | grep USB4
c3:00.5 USB controller: AMD USB4 Router 0
c3:00.6 USB controller: AMD USB4 Router 1
Thanks for any insight. Happy to provide additional logs or test patches.