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

Hello David,

On 8/22/2026 5:16 PM, David Smith wrote:
> 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.

Thank you for the detailed report. May I ask if the same problem reproduces
with powersave governor + performance EPP. Essentially:

  echo powersave | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
  echo performance | tee /sys/devices/system/cpu/cpu*/cpufreq/energy_performance_preference

It will help narrow down if this is indeed an EPP thing or there are more
OS side interactions needed to observe the sync flood.

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

I see you are on latest ucode but your BIOS seems to be slightly outdated
based on the information on Bugzilla. From a quick Google search, I see a
new version (01.25.00 Rev.A) available for your system at
https://support.hp.com/si-en/drivers/hp-probook-445-g8-notebook-pc/38228745

Could you try updating your BIOS and check if this is still reproducible?

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

I couldn't find anything specific that links to CPPC autonomous selection
+ sync flood but my hunch is with DC + Performance EPP, the SMU is probably
misjudging the power distribution and that leads to an unexpected
CPU + iGPU + fabric power distribution which causes this.

> 
> 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?

Yes! With DC, the operating assumptions changes since the power envelope
is more limited. Plus, there may be additional tuning from vendors to
make a trade off between performance, thermals, and battery life.

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

I'll let Mario answer this since he may have more background.

> 
> 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?

Again, I'll defer to Mario since he knows the features on the client
side better.

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

Thank you again for all the experiments and figuring this workaround.

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

Let me go look more at the data there but re-checking with the latest BIOS
just in case something already solved this would be great if possible.

-- 
Thanks and Regards,
Prateek