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

On 8/26/26 15:35, Lovekesh Solanki wrote:
> On Tue, Aug 25, 2026 at 11:43:22PM +0200, Mathieu Fluhr wrote:
>> The patch you sent makes the issue go away. I am now running the exact same
>> scenario for 2 hours, without any crash.
> That's good, thanks for confirming.
> 
>> However, I am not sure if this can qualify for a proper fix, since I
>> do not have any
>> external hub connected to my motherboard: All my USB devices are directly
>> plugged into root hubs (and at the moment, there is only a keyboard and a
>> mouse).
> Yeah that's the point it only skips the 200ms hold for root hubs. The
> external hubs still get their fair hold since a parent exists for them.
> So external hubs are completely unaffected by this patch.
> 
> On 'proper fix', I think it is, even if we keep this bug seperate for a
> moment, it makes sense to not give root hubs hold they don't need.
> 
> I'd love to hear more thoughts on the patch.
> 

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).

Mathieu, would it be possible to test different values for
USB_SS_PORT_U0_WAKE_TIME in hub.c? Especially 120ms is interesting.

See when system no longer crashes

Thanks
Mathias