Re: [REGRESSION] 6.12.36+: usb: hub: post-resume delayed work triggers > uncorrected MCE / data fabric sync flood on Threadripper 7970X > (bisected to aec11e5f9c45)
Lovekesh Solanki <[email protected]>
| Newsgroups | dev.linux.lists.regressions,org.kernel.vger.linux-kernel,org.kernel.vger.linux-usb,org.kernel.vger.stable |
|---|---|
| Message-ID | <ao8bM2SrASNh2u84@eggarch> |
On Wed, Aug 26, 2026 at 04:40:14PM +0300, Mathias Nyman wrote: > Roothub needs some time to settle as well, but 200ms might be excessive. > > xHC can triggers wake (PME) when a connected USB3 device starts signalling wake, > but port registers changes are not always visible to driver before link training > between roothub and device is successful. > > My educated guess is that 120ms should always be enough for the roothub. > This is also the lecagy msleep() still apparently left in xhci resume > to detect port changes in xhci runtime resume if there are USB3 devices. > That msleep was supposed to be removed now that we got the hub changes. > > This 120ms can probably be further tuned for roothub in some cases, > especially if resume is due to userspace action instead of xHC wake signal (PME). So the patch I sent above unintentionally brought the total hold from hub and xhci side down to 120ms, which worked. And the correct fix would be to bring USB_SS_PORT_U0_WAKE_TIME down to 120ms and clean up the msleep from xhci_resume? I can prepare a patch that addresses both if you'd like. Regards, Lovekesh