Re: [REGRESSION] 6.12.36+: usb: hub: post-resume delayed work triggers > uncorrected MCE / data fabric sync flood on Threadripper 7970X > (bisected to aec11e5f9c45)

[Mathias Nyman <mathias.nyman@linux.intel.com>]

On 8/26/26 21:11, Lovekesh Solanki wrote:
> 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?

120ms for the USB3 roothub, I'd keep the 200ms for external hubs

> 
> I can prepare a patch that addresses both if you'd like.

Sounds good, but better to split the hub and xhci changes into separate patches.

The hub.c tuning might end up in stable as it mitigates the issue seen on
unfixed AMD based platform.

Thanks
Mathias