[Bug 221822] tb-retry.patch (against drivers/thunderbolt/tb.c): makes USB4 link setup resilient to transient sideband failures on AMD hosts with slow-to-ready device routers.

[bugzilla-daemon@kernel.org]

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

--- Comment #1 from j. james johnson (j.jamesjohnson@icloud.com) ---
The 3-site retry patch (CL2→CL0s/CL1 fallback on *any* CL-enable error; 3×
retry with 100/200/300 ms backoff on
`tb_enable_clx`/`tb_enable_tmu`/`tb_tunnel_usb3`/`tb_tunnel_activate`) was
ported to the **shipping distro kernel `7.0.14-8-pve`** (pve-kernel build with
patch applied as `patches/kernel/0052-...`) and is now the daily driver on this
host. Results correct the original report:

- **Boot-attached hub self-recovers after ~2 failed cycles (~252 s) — no
hotplug.** This invalidates the report's claim that boot-attached USB3 tunnel
creation is a hard failure point requiring a device reset. 

- **CL-state and TMU failures eliminated** — the CL2→CL0s/CL1 fallback absorbs
them.
- **The link lane-bonds at 40 Gb/s** on the successful cycle (`link width set
to symmetric, dual lanes`) — the original Summary's "never bonds" is wrong;
bonding occurs whenever lane 1 trains in time, and the retries keep the session
alive long enough for that to happen.
- **New errno data:** the winning cycle logged `PCIe Down path activation
failed: -13` (EACCES) twice before succeeding, alongside the `-107` (ENOTCONN)
seen on failing cycles. Both are transient sideband/port-state races during
device-router enumeration; retry recovers both.
- **BIOS excluded:** flashed board BIOS 1.06 (which adds a retimer GPIO-detect
change). Retimer sideband reads unchanged — lane-0 NVM still all-zeros, lane-1
retimer still never responds. Firmware is not the active variable; tracked
separately with the board vendor.
- 5 HDDs + PCIe/USB3 devices stable under sustained load (I/O at platter speed)

Open, load-tested asks to restate to upstream when the thread is next touched:
(a) retry-with-backoff on transient CL/TMU/USB3/PCIe-path-activation failures;
(b) CL2→CL0s/CL1 fallback on any CL-enable error, not just `-EOPNOTSUPP`; (c)
re-attempt `tb_switch_set_link_width(DUAL)` when the second lane reaches
`TB_PORT_UP` late — single-lane sessions still occur on cycles where lane 1
trains after the initial bonding attempt.

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

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