freenode
Kernel & Low-Level

Stable kernel USB hub change crashes Threadripper under ADB load

A 6.12 stable backport meant to wake nested USB3 devices is blamed for hard MCE resets when Android tooling hammers the root hub.

A regression in Linux 6.12.36 and later can hard-reset AMD Threadripper workstations, producing uncorrected machine checks and data-fabric sync floods when the system idles with Android Debug Bridge activity on the USB bus.

Mathieu Fluhr reported the failure on a Threadripper 7970X after daily Android emulator builds on Ubuntu. Freezes and automatic reboots struck within minutes of leaving an emulator idle. Older Ubuntu HWE kernels were fine; mainline testing pinned the break to the 6.12 stable series. Limiting the CPU to shallow idle states avoided the crash but was only a stopgap.

The change at fault is a stable backport of a USB hub fix that holds SuperSpeed hubs awake for a short post-resume window so deeply nested USB3 devices behind suspended hubs can train their links. Kernel regression tracker Thorsten Leemhuis noted at least three earlier reports, all tied to adb, and said a proper fix had stalled for months.

Lovekesh Solanki argued against a full revert. The hold is useful for external hubs and Thunderbolt docks, but root hubs have no upstream peer to wait for, and the host controller already handles late USB3 training. Root hubs also autosuspend immediately, so the extra awake time is the only stretch in the cycle. adb’s repeated open and close of USB device nodes forces the whole host through resume and suspend; on affected machines each SuperSpeed root-hub cycle ballooned from tens of milliseconds to well over 200, pushing suspend into delayed work and creating a roughly one-hertz stress pattern that some AMD xHCI silicon does not tolerate.

Solanki posted a narrow patch that applies the hold only when the hub has a parent, preserving dock behavior while sparing root hubs. Michal Pecio said that approach likely helps those systems but questioned whether the underlying failure is a pure software race or undefined hardware behavior when the controller is poked during certain power transitions, and whether similar timing could still bite external hubs under other workloads.

Until a fix lands, users hit by the issue have relied on keeping the xHCI PCI function from suspending or blocking deeper CPU idle states. Fluhr’s report shows new victims are still finding the bug long after the first filings.