Proposed Linux Patch For A Brief Delay To Match PCI Spec Will Hopefully Address Some Bugs
Proposed Linux Patch For A Brief Delay To Match PCI Spec Will Hopefully Address Some Bugs
https://www.phoronix.com/news/Linux-Delay-D3cold-Patch-Fix
Publish Date: 2026-07-09 09:35:00
Source Domain: www.phoronix.com
Going back to February there was a bug report around the xHCI controller dieing on resume from s2idle when using an AMD Ryzen AI Max+ “Strix Halo” Framework Desktop. In turn all USB devices behind the xHCI controller are lost on resume, but unbinding and binding the driver can restore the functionality without a reboot. After months of back and forth communication, it looks like a solution has been figured out and comes down to a nuance of the PCI spec with needing a brief wait.
Framework Computer originally reported this Linux kernel bug that customer(s) experienced. AMD Linux engineer Mario Limonciello ultimately devised a patch that appears to properly address this scenario of the xHCI controller being lost on resume for some hardware.
The PCI specification outlines a minimum recovery time between programming a function from D3 to D0 and accessing it. That is a 10ms delay outlined in the PCI specification. But the Linux kernel doesn’t have any mandatory delays in the D3cold path but only for D3hot. With the now-pending Linux kernel patch, a 10ms delay is ensured on the D3cold path and in turn it looks to resolve this issue.
Limonciello explained on the kernel mailing list:
“An issue has been reported that xHCI host controller doesn’t come back from resume on some systems. This issue has a failure rate, but that failure rate is confusingly tied to the size of the VRAM reservation that the BIOS makes.
That is if the VRAM reservation is small (for example 512MB) then no failures. There are some comments that mention that the larger the VRAM size the higher the failure rate. I personally don’t really understand why this would matter, but I would like to mention it in case it jogs anyone else’s brain.
Various workarounds work:
* Using legacy interrupts instead of MSI
* Resetting controller on resume
* Creating device link dependency between XHCI and display PCI devices (for device resume ordering)
None of those workarounds appear to get at the root of…