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

> The behavior that is described here sounds like a platform firmware bug
> Are you on the latest BIOS available from your OEM?

Ywa, And I even rolled back 2 BIOS before, All 3 are showing the issue...
...even the exact same one (with the exact same CMOS settings) that I
used in 2024 without any single issue.

> Can you please confirm:
> Your CPU model number/codename
AMD Ryzen Threadripper 7870X 32.Cores

mathieu@ubuntu:~$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 25
model : 24
model name : AMD Ryzen Threadripper 7970X 32-Cores
stepping : 1
microcode : 0xa10810c
cpu MHz : 2188.582
cache size : 1024 KB
physical id : 0
siblings : 64
core id : 0
cpu cores : 32
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 16
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt
pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl xtopology
nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor
ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx
f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a
misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core
perfctr_nb bpext perfctr_llc mwaitx cpuid_fault cpb cat_l3 cdp_l3
hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall
fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq
rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw
avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc
cqm_mbm_total cqm_mbm_local user_shstk avx512_bf16 clzero irperf
xsaveerptr rdpru wbnoinvd amd_ppin cppc arat npt lbrv svm_lock
nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter
pfthreshold avic vgif x2avic v_spec_ctrl vnmi avx512vbmi umip pku
ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg
avx512_vpopcntdq la57 rdpid overflow_recov succor smca fsrm flush_l1d
debug_swap
bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass srso
spectre_v2_user tsa vmscape
bogomips : 7988.27
TLB size : 3584 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 52 bits physical, 57 bits virtual
power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14]
[..]

2. Your OEM (from /sys/class/dmi/id)
I am using an ASUS Pro WS TRX50-SAGE WIFI

root@ubuntu:/home/mathieu# cat /sys/class/dmi/id/board*
Default string
Pro WS TRX50-SAGE WIFI
231230340100705
ASUSTeK COMPUTER INC.
Rev 1.xx

3. OEM BIOS version (from /sys/class/dmi/id)
root@ubuntu:/home/mathieu# cat /sys/class/dmi/id/bios*
02/03/2026
13.17
American Megatrends Inc.
1317

4. AGESA version (see commit bc91133e260c8113c1119073c03b93c12aa41738 if
the OEM didn't tear it out.  Otherwise look in BIOS menus)?

The BOIS shoes this information (I also put the ones from previous
BIOS I tested):
BIOS 1317: ComboSP6PI 1.0.0.1e
BIOS 1203: ComboSP6PI 1.0.0.1a Patch A
BIOS 0803: StormPeakPI_1.1.0.0g

On Tue, Aug 25, 2026 at 12:09 AM Mario Limonciello
<[email protected]> wrote:
>
>
>
> On 8/24/26 14:37, Mathieu Fluhr wrote:
> >> The issue is obviously a severe HW malfunction (you mentioned MCEs, the
> >> Ryzen CPUs simply totally locked up), triggered by poking certain xHCI
> >> controllers on the I/O die of these CPUs in some wrong way.
> >
> > Yes. As mentioned, I first thought that the emulator itself triggered that by
> > doing something that the CPU did not like.To be honest, I barely play with old
> > Android versions anymore, but seeing that I could reproduce it even with
> > Android 13 or 14 made me suspicious.
> >
> > I _guess_ Google implemented a workaround inside adb for version Android
> > 15 since using this version, it remains stable for more than 2 hours.
> >
> > But, in the end, the situation is that from a simple user account having access
> > to some usb plugged in devices (I usually add my user account to the plugdev
> > group and use some known udev rules to access my Android tests devices),
> > you have a way to crash the complete system.
> >
> >> Opinions seem to vary on whether CPU load must be present or absent.
> >
> > On my side (and I am here only speaking about my TR. I don't know about
> > other Ryzen CPUs), I can't reproduce it under load, and one condition to
> > reproduce it is my CPU going in C2 state.
> > -> I did a 2:30 hour test using several youtube videos playing at the same
> > time on my desktop, also stressing the emulator with some 3D Mark runs
> > (as mentioned, I first suspected the nvidia driver to be faulty). As long as my
> > computer was busy everything went fine. But then I let it stand still for a few
> > minutes, and it just crashed.
> >
> > If you need me to do some further tests or experiments, let me know. I will
> > be more than happy to play the guinea pig here.
> >
> The behavior that is described here sounds like a platform firmware bug
> to me.  Are you on the latest BIOS available from your OEM?
>
> Can you please confirm:
>
> 1. Your CPU model number/codename
> 2. Your OEM (from /sys/class/dmi/id)
> 3. OEM BIOS version (from /sys/class/dmi/id)
> 4. AGESA version (see commit bc91133e260c8113c1119073c03b93c12aa41738 if
> the OEM didn't tear it out.  Otherwise look in BIOS menus)?
>