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

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

I reverted to the stock version of hub.c, and changed the
USB_SS_PORT_U0_WAKE_TIME to 120.
-> No crash for 1 hour, but I will test this deeper this evening.

Where I am a bit puzzled is that Mario Limoncello from AMD just confirmed
that this was a platform issue, only affecting StormPeak, for which AMD already
has a fix.... Or maybe there are more than one issue here?

On Wed, Aug 26, 2026 at 3:40 PM Mathias Nyman
<[email protected]> wrote:
>
> 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
>