amd-pstate: Cezanne data fabric sync flood on DC gated by CPPC max_perf

Hi,

I have a reproducible AMD data fabric sync flood (reset code 0x08000800) on
an HP ProBook 445 G8 (Ryzen 7 5800U, Cezanne, family 25 model 80 stepping 0)
that appears to be gated by the CPPC max_perf value in combination with EPP,
and not by any physical operating point. 13 confirmed hard resets.

Bugzilla, with full data and a 770 KB evidence attachment:
https://www.google.com/url?q=https://bugzilla.kernel.org/show_bug.cgi?id%3D221909&source=gmail&ust=1787484988593000&sa=E

x86/amd: Previous system reset reason [0x08000800]: an uncorrected error
caused a data fabric sync flood event

Summary of the controlling experiment. All rows are on battery, same pack,
same charge range, same workload (llama.cpp 128-token prefill, ~6.7GB model,
CPU only, held warm). Peaks are from amdgpu hwmon plus RAPL:

EPP / governor smax_freq max_perf fmax vddgfx tctl steps deaths
balance_performance / powersave 4508086 166 3617 1175mV 63.8C 12 4
balance_performance / powersave 4500000 165 - - - 1 1
balance_performance / powersave 4100000 ~151 4017 - 84.9C 8 0
balance_performance / powersave 3800000 140 3748 1275mV 71.5C 33 0
performance / performance 4508086 166 4374 1462mV 85.8C 8 0
balance_power / powersave (AC) 4508086 166 4117 1431mV 84.0C 8 0

Rows 1 and 5 are the interesting pair: identical scaling_max_freq, identical
power source, identical workload, differing only in EPP and governor. Row 5
runs 757 MHz faster, 287 mV higher and 22 C hotter than row 1 and survives
8/8, while row 1 dies about 14 seconds into a step.

So: pinning perf high is safe, clamping the range low is safe, and lethal is
the wide range with autonomous SMU ramping - balance_performance + powersave
across max_perf 166 on DC. This looks to me like autonomous perf-state
transition handling on DC rather than any operating point the part reaches.
Consistent with that, scaling_max_freq=3800000 prevents it even though the
workload never exceeds ~2.9 GHz uncapped; the cap narrows the range rather
than lowering the ceiling.

Never reproduced on AC. Reproduced on 7.1.8 and 6.18.44-lts, and on BIOS
01.21.00 and 01.22.00. amd-pstate-epp, status active, prefcore enabled.
Microcode 0xa500014, verified loaded.

Ruled out: memtest86+ 7.20 five passes clean; HP preboot diagnostics all
pass; thermal (dies at 63.8C, survives at 85.8C); NVMe HMB (AER is OS-owned
and clean, ASPM disabled by FADT); OOM. Also the battery pack, which is worn
(~430 mOhm, sags to 9.48V under load) and was my leading hypothesis until the
row-1-vs-row-5 control above rejected it - no battery model fails at
3617 MHz / 1175 mV and succeeds at 4374 MHz / 1462 mV on the same charge.

Note this is a single machine. I have not been able to confirm it on another
445 G8 or another 5800U, so I cannot rule out that it is specific to this
unit.

Questions:

1. Is there a known Cezanne erratum covering data fabric sync floods
triggered by autonomous CPPC perf-state transitions on DC?

2. Is the DC vs AC asymmetry expected - does the SMU run a materially
different perf-state transition policy on DC that could expose this?

3. Would a DMI-matched amd_pstate quirk clamping max_perf on DC be
acceptable upstream for affected platforms, or is this strictly an
AGESA/PMFW fix to route through the OEM? I am happy to write and test
the patch if you tell me the shape you would accept - I did not want to
send one cold given amd_pstate has no AC/DC awareness today.

4. Is there any way to get a fabric-side error record on a platform with no
APEI tables (no BERT/HEST/ERST here), to identify which agent flooded?

Current workaround, if useful to anyone hitting this: cap scaling_max_freq
to 3800000 on DC only. 33 ladder steps plus a 35 minute mixed-load soak at
load average 29-34 with zero resets, against 5 deaths in 13 uncapped steps.

Happy to run further tests on this machine - it reproduces in under a minute
and I have it instrumented at 5 ms resolution. I have the full boot ledger of
all 13 resets, per-crash triage, and the 5 ms RAPL/hwmon sample sets for every
row above; the bugzilla attachment has all of it.

Thanks,
Dave Smith