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

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

[David Smith]

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

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

[K Prateek Nayak]

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

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

[K Prateek Nayak]

Hello David,

On 8/27/2026 7:27 AM, David Smith wrote:
> Hi Prateek,
> 
> Thank you for the quick reply, and apologies for the delay - I wanted to come back with the BIOS result you asked for rather than a partial answer.

No worries and thank you for the detailed report. Since the
mailing list dropped your reply, I'll retain it in wholly for
record on the thread.

> 
> Short version: I tested 01.25.00 as you asked and it did not fix it. I also owe you a correction: two rows of the table I sent are invalid and I have withdrawn them. One of them is the row your hypothesis rests on, so please read that part first. I have posted the same corrections to bugzilla 221909
> (comment #4) so the public record is not misleading.
> 
> (Dropping gautham.shenoy@amd.com <mailto:gautham.shenoy@amd.com> - it bounced, "Recipient not found".)
> 
> 1. THE BIOS UPDATE YOU ASKED FOR: 01.25.00 DIES
> ===============================================
> Flashed and verified three ways (DMI, HP's own tool, and the DEVFW image on the stick). Confirmed before the run that the operating point was unchanged across the flash, so the ladder is comparable.
> 
> BIOS T78 Ver. 01.25.00, kernel 7.1.8, battery 96%, uncapped
> 06:46:42 warm: RSS=6692 MiB, MemAvailable=5892 MiB, 26.8 tok/s <- arm VALID
> 06:46:58 STEP 1 (short) survived 1.92 s
> 06:47:08 STEP 2 (128-token prefill) opened
> 06:47:53 next boot, reset reason 0x08000800
> 
> 23 seconds. So this rules out AGESA CezannePI FP6 1.0.1.1c and PSP 0.11.0.85 -> 0.11.0.88, and everything else in HP's 01.23/01.24/01.25 deltas.
> 
> But it does not touch your hypothesis, and I want to be explicit about why: across 01.22 -> 01.25 the SMU firmware is unchanged at 64.74.0 and the microcode is unchanged at 0xa500014. The flash did not move the component you accused. I wrote that down before the run so it could not be read either way afterwards.
> 
> 01.25 is the latest HP ships, so the BIOS avenue is now closed from my side.
> 
> 2. THE CORRECTION: ROWS 3 AND 5 ARE WITHDRAWN
> =============================================
> Re-deriving my arm ledger from raw logs, the surviving runs at stock max_perf shared a defect: the 6.7 GB model was not actually resident, so they were I/O-bound on page-ins instead of running sustained all-core AVX2. They were not doing the same work as the runs that died.
> 
> Row 5, performance/performance 4508086, "8 steps 0 deaths": entered the window with 10 MiB MemAvailable, holding 5004 MiB of a
> ~6.7 GiB model, at 17.3-24.2 tok/s. My 3.8 GHz-capped run manages 30.7-31.2 tok/s. A run pinned to max_perf 166 that is 30% slower than a capped run was not stressing the part. Its quoted fmax 4374 MHz was a transient peak in a starved run; mean fmax was 2953 MHz.
> 
> Row 3, balance_performance/powersave 4100000: same defect, worse - RSS 38 MiB.
> 
> So the row-1-vs-row-5 pair, "pinning perf high is safe", and my claim to have excluded the battery all have no valid arm behind them. I am sorry for sending
> that as the headline result.
> 
> Row 5's configuration has since been re-run properly (RSS 6692 MiB, MemAvailable 12.6 GiB, 27.9 tok/s warm). It DIED.
> 
> This matters for your hunch specifically. You suggested "DC + Performance EPP, the SMU is probably misjudging the power distribution". On this machine epp=performance is not protective - it is one of the configurations that kills it. That exact experiment had in fact already run on 2026-08-24 07:46, before your mail arrived (gov=powersave, epp=performance, smax=4508086, battery 91%):
> it hard-reset with 0x08000800 during model warm-up, ~3 s in.
> 
> I have now seen deaths at balance_power, balance_performance and performance alike, and with min_perf pinned equal to max_perf. EPP is not the gate.

Thank you for confirming!

> 
> 
> 3. THREE MORE NEGATIVE RESULTS SINCE WE LAST SPOKE
> ==================================================
> All on battery, stock max_perf, with guards on RSS >= 6000 MiB, MemAvailable >= 1500 MiB and warm throughput >= 25 tok/s.
> 
> (a) CC6 disabled: died in 10 seconds. Verified at 0 CC6 entries/s (normal arms measure 3420-4403/s), so this is not "C6 reduced" - the machine executed zero C6 entries and still flooded. This also refutes
> processor.max_cstate=2, which is the most-recommended workaround in the community gist now linked from the bugzilla.
> 
> (b) Kernel 6.12.75 died in 20 seconds. The bugzilla now has reports naming 6.12.x as last-known-good against 6.18.x/7.1.x failing - exactly my confirmed pair. I gated the test in advance so a survival could not be
> dismissed: 6.12.75 reaches a harsher operating point than 7.1.8 (3.67% vs 2.94% of core-samples above 3.8 GHz). It died anyway, at the same step as every other death. Incidentally the two kernels derive different limits from the same hardware - cpuinfo_min_freq 1113443 -> 400000 - though
> the per-core highest_perf ladder is identical. Is the boost-numerator / _CPC derivation change between those kernels worth pursuing, or does this
> result close it?

Between v6.12 and v6.17 we began deriving the cpuinfo_min_freq from the
CPPC Min Perf and Nominal Frequency in the _CPC object instead of just
setting it to Lowest Frequency advertised in _CPC.

I've requested for some more data below on this point.

> 
> (c) I also have to withdraw my "range, not ceiling" interpretation. I told you the cap works by narrowing the CPPC range and that the workload never
> exceeds ~2.9 GHz uncapped. That came from an unreliable fmax field. Re-measured with per-core CPPC delivered/reference counters:
> 
> STOCK (4508086) CAPPED (3800000)
> p99 3981 MHz 3752 MHz
> p99.9 4171 MHz 3963 MHz
> max 4473 MHz 4493 MHz
> core-samples > 3.8 GHz 1271 (2.94%) 93 (0.21%)
> 
> The workload does reach 4.2-4.5 GHz. The cap cuts the above-3.8 GHz population 13.8x while leaving the median untouched (2336 -> 2331 MHz) - it acts entirely on the tail. The excursions concentrate in low-thread phases (cold load, page faults, memcpy, NVMe completion), not the all-core vector phase, and per-core counts track the CPPC preferred-core ranking
> exactly (the four highest_perf=196 cores carry the most). Note the cap is statistical, not absolute - 0.21% still exceed it, peaking at 4493 MHz.
> 
> 
> 4. THE MOST USEFUL THING I HAVE: IT CORRUPTS DATA BEFORE IT RESETS
> ==================================================================
> The last kernel line before one reset was a userspace fault in the compute workload, which the kernel resolved to a specific instruction:
> 
> traps: llama-server[34143] general protection fault ip:74fd9014dbd7 error:0 in libggml-cpu-haswell.so[e0bd7,74fd9007f000+d8000]
> 
> File offset 0xe0bd7 is inside ggml_gemm_q4_K_8x8_q8_K, the hottest loop of
> the workload:
> 
> e0bc4: mov 0x1b8(%rsp),%rax ; base pointer from stack e0bcc: add (%rsi),%rax ; += an 8-byte word from memory e0bd3: add $0x8,%rsi e0bd7: vmovdqu 0x10(%rax,%r12,1),%ymm0 ; <-- FAULTS HERE
> 
> The same instruction faulted at the earlier crash that produced the MCE (identical ip low-20 bits) - but that time as a SIGSEGV (error 4, page-not-present) on a canonical-but-unmapped address, rather than a #GP on a non-canonical one.
> 
> vmovdqu is the unaligned load and does not raise #GP on misalignment, so both faults are bad *addresses*, and %rax is built from two memory loads two instructions earlier. Same instruction, two fault types, two different bad addresses - that is a corrupted pointer operand, not a software bug.
> 
> Which is precisely what the MCE said: IPID 0x001000b0_00000000 -> SMCA_LS_V2,
> XEC 1, "An ECC error or L2 poison was detected on a data cache read by a load", Poison set, OVER set, PCC=0, on two cores at two addresses in the same instant. The LS unit is the consumer of an already-poisoned line. Which upstream unit sets poison on this part? That would let me trace from consumer to
> originator, and it is my question 2 on the bugzilla.
> 
> Control: the workload has faulted exactly twice, both within seconds of a sync flood, across ~14 valid stock-max_perf arms - and zero times across 43 capped ladder steps and two capped soaks.
> 
> So this machine computes wrong answers before it resets. Both observed cases corrupted a pointer and were therefore loud; corruption of a value would
> be silent.
> 
> One timing caveat, because it cuts against a simple di/dt story: in most recent deaths the compute load collapses to idle 0.3-2.8 s before the reset - in
> one case the machine sat at ~9 W for nearly three seconds after the workload had already died. It is not universal (one arm died under full load), but
> time-of-death is evidently not time-of-injection.
> 
> Correction to my earlier mail while I am here: I quoted that MCE with "... in libggml-cpu-haswell.so <http://libggml-cpu-haswell.so/>" appended. The raw journal line carries no library attribution - the kernel did not resolve the vma that time. The library identification for that crash rests on the ip-bit match above, not on the log text.
> 
> 
> 5. THE BATTERY, HONESTLY
> ========================
> You confirmed the SMU runs materially different assumptions on DC. That removed the argument I was leaning on: I had treated "survives on AC" as evidence the power source is not the issue. If the DC policy is genuinely different, AC survival is equally consistent with a firmware policy problem and a DC power-path problem, and does not separate them.
> 
> The pack is measurably bad. Measured under load at 82% charge:
> 
> voltage_min_design 11.400 V voltage_now 10.981 V <- 419 mV below its own design floor
> current_now 2.234 A at only 2.2 A average
> charge_full/design 76.1% 263 cycles, 5 yr 4 mo
> 
> I previously claimed to have excluded it; with row 5 withdrawn that claim was not sound and I withdraw it too.
> 
> I am not going to be able to test a replacement pack. I would rather tell you that than leave you waiting on a result that is not coming. So the DC power
> path stays open on my side, and I would not want AMD to spend time on a pure firmware theory on the strength of an exclusion I have retracted.

Thank you for the transparency. I'll talk to the SMU folks internally to see
if these symptoms ring a bell.

 
> 6. WHERE IT STANDS
> ==================
> At stock max_perf on DC: 13 deaths in 14 valid arms
> At smax <= 3800000 on DC: 43 ladder steps + a 35-min mixed soak + a 20-min integrity soak, 0 deaths
> 
> Nothing has moved that gate: BIOS 01.22, BIOS 01.25, EPP, governor, min_perf pinning, CC6 off, and three kernels. Only the frequency cap does.
> 
> I also built a self-verifying canary (bit-exact AVX2 checksum, single-bit-flip selftest 60/60) and ran four instances on the CPPC preferred cores alongside
> the real workload, on battery under the cap, for 20 minutes: ~557,000 verified passes, ~17 TiB checked bit-exactly, zero compute errors, zero memory
> corruption, zero faults, zero MCEs, no reset. Caveat: those canaries held their cores at sustained 100%, which does not produce the idle->boost transition
> where section 3 puts the excursions, so that result does not yet cover the excursion case.
> 
> Still happy to run anything you want on this machine - it reproduces in 10-50 s on demand, and I have per-crash triage, CPPC-counter frequency distributions and 5 ms RAPL/hwmon sample sets for every arm.

Thanks a ton for all the data. After a boot, could you share the data
from running:

  grep -r . /sys/devices/system/cpu/cpu0/acpi_cppc/
  grep -r . /sys/devices/system/cpu/cpu0/cpufreq

Also, does this issue reproduce if you add "amd_pstate=disable" in your
kernel cmdline, reboot into same kernel, and run the benchmark?

You'll have the acpi-cpufreq driver running which does _PST P-states
based scaling but the boost frequencies are completely controlled by
SMU firmware still.

It will help narrow down if a specific CPPC path triggers it for out
SMU folks.

Note: You'll need to do a full reboot and not a kexec since some bits
of CPPC based scaling cannot be disabled without a full reset.

Thanks a ton again for all the data.

-- 
Thanks and Regards,
Prateek

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

[David Smith]

Hi Prateek,

Thank you for retaining the dropped reply on the thread - and
apologies for sending it as HTML, that was my mistake. Plain text from
here on.

Both of your questions first, then one new result that changes what I
told you about voltage.


1. THE CPPC / CPUFREQ DUMPS YOU ASKED FOR
=========================================
Kernel 7.1.8-arch1-3, BIOS T78 01.25.00, on battery, current boot.

One thing to flag before you read it: scaling_max_freq below reads 3800000
because my own mitigation applies that cap on DC. It is not a stock value.
Stock is cpuinfo_max_freq = 4508086. Everything else is untouched.

# grep -r . /sys/devices/system/cpu/cpu0/acpi_cppc/
highest_perf:181
nominal_perf:70
lowest_nonlinear_perf:41
lowest_perf:15
reference_perf:70
nominal_freq:1901
lowest_freq:400
guaranteed_perf:0
feedback_ctrs:ref:727350219481 del:635505385681
wraparound_time:18446744073709551615

# grep -r . /sys/devices/system/cpu/cpu0/cpufreq
scaling_driver:amd-pstate-epp
scaling_governor:powersave
energy_performance_preference:balance_performance
energy_performance_available_preferences:default performance
balance_performance balance_power power custom
scaling_cur_freq:2315367
cpuinfo_avg_freq:2315367
scaling_min_freq:1113443
scaling_max_freq:3800000 <- my DC cap, not stock
cpuinfo_min_freq:407358
cpuinfo_max_freq:4508086
amd_pstate_max_freq:4508086
amd_pstate_lowest_nonlinear_freq:1113443
amd_pstate_highest_perf:166
amd_pstate_prefcore_ranking:181
amd_pstate_hw_prefcore:enabled
boost:1
scaling_available_governors:performance powersave
cpuinfo_transition_latency:0
affected_cpus:0
related_cpus:0

On your point about the v6.12 -> v6.17 derivation change, the
arithmetic here matches your description exactly:

lowest_perf * nominal_freq / nominal_perf = 15 * 1901 / 70 = 407.4 MHz
cpuinfo_min_freq = 407358

against lowest_freq = 400 MHz, which is what 6.12 would have used.

In my last mail I said the two kernels derive "cpuinfo_min_freq
1113443 -> 400000". That was sloppy: 1113443 is scaling_min_freq /
amd_pstate_lowest_nonlinear_freq, not cpuinfo_min_freq. The actual
cpuinfo_min_freq on 7.1.8 is 407358 as above. Please use these numbers
rather than the ones in that paragraph.


2. amd_pstate=disable: YES, IT STILL REPRODUCES - AND IT GETS WORSE
===================================================================
I ran this twice, on a full reboot with amd_pstate=disable on the
cmdline (not kexec), same kernel, acpi-cpufreq active, on battery.

arm 1: died 98 s in, near idle
arm 2: died 25 s in, during model load
both: 0x08000800, same signature

So the CPPC / amd-pstate path is NOT necessary for the failure.

I want to be careful about how much that is worth, because neither arm
reached my measured ladder - both died before it - so I have no graded
hazard number under acpi-cpufreq, only "it died, fast, twice". I am
not claiming a ladder result.

And there is a confound you should have, because it cuts against
reading this as "acpi-cpufreq is worse":

- under acpi-cpufreq, scaling_max_freq clamps to the top _PST entry
(1900000), so my 3.8 GHz DC mitigation becomes a NO-OP and boost is
entirely SMU-autonomous - I measured 4478 MHz on battery in that state
- the P-state floor also rises, to 1600000, versus amd-pstate's 407358

So that boot is simultaneously uncapped and higher-floored. The
reading I would stand behind is therefore not "acpi-cpufreq is
dangerous" but: whenever the effective frequency ceiling is
uncontrolled on DC, the machine dies - under either cpufreq driver.
Whenever it is capped at 3.8 GHz on DC, it does not.

If it would help your SMU discussion to have a properly ladder-scored
acpi-cpufreq arm, tell me how you would like the ceiling controlled in
that state and I will run it.


3. NEW: A SINGLE-VARIABLE PAIR - AND IT KILLS MY OWN VOLTAGE THEORY
===================================================================
This is the only experiment I have where exactly one variable moves,
and it falsifies the mechanism I was building toward in my last mail.

Both arms: same boot, same machine, same battery, same workload
(llama.cpp 128-token prefill, ~6.7 GB model, verified resident, CPU
only), 27 minutes apart. Both with amdgpu
power_dpm_force_performance_level=high, which pins FCLK at its top DPM
state. CPU VDD plane sampled at 492 Hz.

LETHAL SURVIVOR
scaling_max_freq 4508086 3800000
FCLK 1333 MHz, 100% 1333 MHz, 100%
FCLK transitions 0 in 23864 samples 0 in 66913 samples
VDDNB (SoC rail) 818 mV 84.5% 818 mV 94.0%
CPU VDD plane, peak 1250 mV 1281 mV
CPU VDD plane, % >=1300 mV 0.00% 0.00%
CPU VDD plane, % 1100-1300 25.6% 33.0%
exposure died at 20.9 s survived 318 s, 9/9 steps
outcome 0x08000800 clean

scaling_max_freq is the only thing that differs.

Two things follow.

(a) CPU-plane voltage is NOT the mechanism. I had built a story where
the cap protects by removing a sustained 1.37-1.39 V operating point,
and I was about to send you that. The pair kills it in the awkward
direction: the run that SURVIVED sat at a HIGHER peak plane voltage
and spent MORE time in the 1100-1300 mV band, for 15x longer exposure,
and lived.

Related provenance correction: I have been quoting a "vddgfx" column
as though it were a GPU rail. It is not - on this part it is the
shared VDDCR_VDD plane and it tracks the CPU V/F point (1 thread:
cores 4574 MHz, plane 1393 mV; 16 threads: cores 2761 MHz, plane 931
mV). I also sampled it at 4 Hz for most of this investigation while it
updates about every 2.7 ms, so roughly 1 value in 92. Any voltage
claim I sent you before this mail was drawn from aliased data.

(b) Fabric DPM transitions are not necessary either. FCLK pinned at
1333 MHz, 100% residency, ZERO transitions across 23864 samples at 492
Hz - and it sync-flooded anyway. I had previously seen FCLK thrash at
50 Hz and wondered if it was causal; in this death it is entirely
absent.

Note also how harsh the survivor's configuration is: FCLK pinned at
1333 MHz is the modifier that kills this machine FASTEST at stock
max_perf - 11.6 s in one arm, 21 s in another. Under the cap it ran
318 s clean.

That leaves, on my side:

excluded: fabric DPM transitions, SoC-rail level, CPU-plane voltage
remaining: peak core frequency itself, or core current / di-dt at the
top P-states

i.e. the fault lives in the top ~700 MHz, between 3.8 and 4.5 GHz, and
is not reachable through the plane voltage, the fabric clock or the
SoC rail. That is the tightest statement I have.


4. WHAT I CANNOT DO FROM HERE, AND ONE OFFER
============================================
I cannot separate frequency from power budget: there is no writable
PPT interface on this part, amdgpu exposes only power1_input
read-only. If there is a debug path to set a PPT limit on Cezanne, I
will use it.

I also cannot witness a droop even in principle. Every voltage and
power number available to me from hwmon is an SMU self-report, and the
one independent instrument - the battery EC - refreshes about every 9
s against an event that lasts under a second. So if your SMU
colleagues can read what this part actually commanded in the final
~900 ms, that would settle a question I have no way to reach.

The offer: the band 3.83-4.45 GHz is entirely untested. My coverage is
<=3.80 GHz (0 deaths, 52 ladder steps), 4.48 GHz (1 death / 1 arm),
4.51 GHz stock (dies reliably). A cap at ~4.1 GHz bisects it and would
give you the threshold. Say the word and I will run it.

Where it stands:

at stock max_perf on DC: 14 deaths in 15 valid arms at smax <= 3800000
on DC: 52 ladder steps + a 35-min mixed soak + a 20-min integrity
soak, 0 deaths

Nothing else has moved that gate - BIOS 01.22 and 01.25, EPP,
governor, min_perf pinning, CC6 off, fabric pinning, and three
kernels.

All of the above is now also on bugzilla 221909 as comment #5, so the
public record carries the corrections too.

Thanks again - happy to run anything your SMU folks want. It
reproduces in 10-50 s on demand.

--dave


On Wed, Aug 26, 2026 at 11:18 PM K Prateek Nayak <kprateek.nayak@amd.com> wrote:
>
> Hello David,
>
> On 8/27/2026 7:27 AM, David Smith wrote:
> > Hi Prateek,
> >
> > Thank you for the quick reply, and apologies for the delay - I wanted to come back with the BIOS result you asked for rather than a partial answer.
>
> No worries and thank you for the detailed report. Since the
> mailing list dropped your reply, I'll retain it in wholly for
> record on the thread.
>
> >
> > Short version: I tested 01.25.00 as you asked and it did not fix it. I also owe you a correction: two rows of the table I sent are invalid and I have withdrawn them. One of them is the row your hypothesis rests on, so please read that part first. I have posted the same corrections to bugzilla 221909
> > (comment #4) so the public record is not misleading.
> >
> > (Dropping gautham.shenoy@amd.com <mailto:gautham.shenoy@amd.com> - it bounced, "Recipient not found".)
> >
> > 1. THE BIOS UPDATE YOU ASKED FOR: 01.25.00 DIES
> > ===============================================
> > Flashed and verified three ways (DMI, HP's own tool, and the DEVFW image on the stick). Confirmed before the run that the operating point was unchanged across the flash, so the ladder is comparable.
> >
> > BIOS T78 Ver. 01.25.00, kernel 7.1.8, battery 96%, uncapped
> > 06:46:42 warm: RSS=6692 MiB, MemAvailable=5892 MiB, 26.8 tok/s <- arm VALID
> > 06:46:58 STEP 1 (short) survived 1.92 s
> > 06:47:08 STEP 2 (128-token prefill) opened
> > 06:47:53 next boot, reset reason 0x08000800
> >
> > 23 seconds. So this rules out AGESA CezannePI FP6 1.0.1.1c and PSP 0.11.0.85 -> 0.11.0.88, and everything else in HP's 01.23/01.24/01.25 deltas.
> >
> > But it does not touch your hypothesis, and I want to be explicit about why: across 01.22 -> 01.25 the SMU firmware is unchanged at 64.74.0 and the microcode is unchanged at 0xa500014. The flash did not move the component you accused. I wrote that down before the run so it could not be read either way afterwards.
> >
> > 01.25 is the latest HP ships, so the BIOS avenue is now closed from my side.
> >
> > 2. THE CORRECTION: ROWS 3 AND 5 ARE WITHDRAWN
> > =============================================
> > Re-deriving my arm ledger from raw logs, the surviving runs at stock max_perf shared a defect: the 6.7 GB model was not actually resident, so they were I/O-bound on page-ins instead of running sustained all-core AVX2. They were not doing the same work as the runs that died.
> >
> > Row 5, performance/performance 4508086, "8 steps 0 deaths": entered the window with 10 MiB MemAvailable, holding 5004 MiB of a
> > ~6.7 GiB model, at 17.3-24.2 tok/s. My 3.8 GHz-capped run manages 30.7-31.2 tok/s. A run pinned to max_perf 166 that is 30% slower than a capped run was not stressing the part. Its quoted fmax 4374 MHz was a transient peak in a starved run; mean fmax was 2953 MHz.
> >
> > Row 3, balance_performance/powersave 4100000: same defect, worse - RSS 38 MiB.
> >
> > So the row-1-vs-row-5 pair, "pinning perf high is safe", and my claim to have excluded the battery all have no valid arm behind them. I am sorry for sending
> > that as the headline result.
> >
> > Row 5's configuration has since been re-run properly (RSS 6692 MiB, MemAvailable 12.6 GiB, 27.9 tok/s warm). It DIED.
> >
> > This matters for your hunch specifically. You suggested "DC + Performance EPP, the SMU is probably misjudging the power distribution". On this machine epp=performance is not protective - it is one of the configurations that kills it. That exact experiment had in fact already run on 2026-08-24 07:46, before your mail arrived (gov=powersave, epp=performance, smax=4508086, battery 91%):
> > it hard-reset with 0x08000800 during model warm-up, ~3 s in.
> >
> > I have now seen deaths at balance_power, balance_performance and performance alike, and with min_perf pinned equal to max_perf. EPP is not the gate.
>
> Thank you for confirming!
>
> >
> >
> > 3. THREE MORE NEGATIVE RESULTS SINCE WE LAST SPOKE
> > ==================================================
> > All on battery, stock max_perf, with guards on RSS >= 6000 MiB, MemAvailable >= 1500 MiB and warm throughput >= 25 tok/s.
> >
> > (a) CC6 disabled: died in 10 seconds. Verified at 0 CC6 entries/s (normal arms measure 3420-4403/s), so this is not "C6 reduced" - the machine executed zero C6 entries and still flooded. This also refutes
> > processor.max_cstate=2, which is the most-recommended workaround in the community gist now linked from the bugzilla.
> >
> > (b) Kernel 6.12.75 died in 20 seconds. The bugzilla now has reports naming 6.12.x as last-known-good against 6.18.x/7.1.x failing - exactly my confirmed pair. I gated the test in advance so a survival could not be
> > dismissed: 6.12.75 reaches a harsher operating point than 7.1.8 (3.67% vs 2.94% of core-samples above 3.8 GHz). It died anyway, at the same step as every other death. Incidentally the two kernels derive different limits from the same hardware - cpuinfo_min_freq 1113443 -> 400000 - though
> > the per-core highest_perf ladder is identical. Is the boost-numerator / _CPC derivation change between those kernels worth pursuing, or does this
> > result close it?
>
> Between v6.12 and v6.17 we began deriving the cpuinfo_min_freq from the
> CPPC Min Perf and Nominal Frequency in the _CPC object instead of just
> setting it to Lowest Frequency advertised in _CPC.
>
> I've requested for some more data below on this point.
>
> >
> > (c) I also have to withdraw my "range, not ceiling" interpretation. I told you the cap works by narrowing the CPPC range and that the workload never
> > exceeds ~2.9 GHz uncapped. That came from an unreliable fmax field. Re-measured with per-core CPPC delivered/reference counters:
> >
> > STOCK (4508086) CAPPED (3800000)
> > p99 3981 MHz 3752 MHz
> > p99.9 4171 MHz 3963 MHz
> > max 4473 MHz 4493 MHz
> > core-samples > 3.8 GHz 1271 (2.94%) 93 (0.21%)
> >
> > The workload does reach 4.2-4.5 GHz. The cap cuts the above-3.8 GHz population 13.8x while leaving the median untouched (2336 -> 2331 MHz) - it acts entirely on the tail. The excursions concentrate in low-thread phases (cold load, page faults, memcpy, NVMe completion), not the all-core vector phase, and per-core counts track the CPPC preferred-core ranking
> > exactly (the four highest_perf=196 cores carry the most). Note the cap is statistical, not absolute - 0.21% still exceed it, peaking at 4493 MHz.
> >
> >
> > 4. THE MOST USEFUL THING I HAVE: IT CORRUPTS DATA BEFORE IT RESETS
> > ==================================================================
> > The last kernel line before one reset was a userspace fault in the compute workload, which the kernel resolved to a specific instruction:
> >
> > traps: llama-server[34143] general protection fault ip:74fd9014dbd7 error:0 in libggml-cpu-haswell.so[e0bd7,74fd9007f000+d8000]
> >
> > File offset 0xe0bd7 is inside ggml_gemm_q4_K_8x8_q8_K, the hottest loop of
> > the workload:
> >
> > e0bc4: mov 0x1b8(%rsp),%rax ; base pointer from stack e0bcc: add (%rsi),%rax ; += an 8-byte word from memory e0bd3: add $0x8,%rsi e0bd7: vmovdqu 0x10(%rax,%r12,1),%ymm0 ; <-- FAULTS HERE
> >
> > The same instruction faulted at the earlier crash that produced the MCE (identical ip low-20 bits) - but that time as a SIGSEGV (error 4, page-not-present) on a canonical-but-unmapped address, rather than a #GP on a non-canonical one.
> >
> > vmovdqu is the unaligned load and does not raise #GP on misalignment, so both faults are bad *addresses*, and %rax is built from two memory loads two instructions earlier. Same instruction, two fault types, two different bad addresses - that is a corrupted pointer operand, not a software bug.
> >
> > Which is precisely what the MCE said: IPID 0x001000b0_00000000 -> SMCA_LS_V2,
> > XEC 1, "An ECC error or L2 poison was detected on a data cache read by a load", Poison set, OVER set, PCC=0, on two cores at two addresses in the same instant. The LS unit is the consumer of an already-poisoned line. Which upstream unit sets poison on this part? That would let me trace from consumer to
> > originator, and it is my question 2 on the bugzilla.
> >
> > Control: the workload has faulted exactly twice, both within seconds of a sync flood, across ~14 valid stock-max_perf arms - and zero times across 43 capped ladder steps and two capped soaks.
> >
> > So this machine computes wrong answers before it resets. Both observed cases corrupted a pointer and were therefore loud; corruption of a value would
> > be silent.
> >
> > One timing caveat, because it cuts against a simple di/dt story: in most recent deaths the compute load collapses to idle 0.3-2.8 s before the reset - in
> > one case the machine sat at ~9 W for nearly three seconds after the workload had already died. It is not universal (one arm died under full load), but
> > time-of-death is evidently not time-of-injection.
> >
> > Correction to my earlier mail while I am here: I quoted that MCE with "... in libggml-cpu-haswell.so <http://libggml-cpu-haswell.so/>" appended. The raw journal line carries no library attribution - the kernel did not resolve the vma that time. The library identification for that crash rests on the ip-bit match above, not on the log text.
> >
> >
> > 5. THE BATTERY, HONESTLY
> > ========================
> > You confirmed the SMU runs materially different assumptions on DC. That removed the argument I was leaning on: I had treated "survives on AC" as evidence the power source is not the issue. If the DC policy is genuinely different, AC survival is equally consistent with a firmware policy problem and a DC power-path problem, and does not separate them.
> >
> > The pack is measurably bad. Measured under load at 82% charge:
> >
> > voltage_min_design 11.400 V voltage_now 10.981 V <- 419 mV below its own design floor
> > current_now 2.234 A at only 2.2 A average
> > charge_full/design 76.1% 263 cycles, 5 yr 4 mo
> >
> > I previously claimed to have excluded it; with row 5 withdrawn that claim was not sound and I withdraw it too.
> >
> > I am not going to be able to test a replacement pack. I would rather tell you that than leave you waiting on a result that is not coming. So the DC power
> > path stays open on my side, and I would not want AMD to spend time on a pure firmware theory on the strength of an exclusion I have retracted.
>
> Thank you for the transparency. I'll talk to the SMU folks internally to see
> if these symptoms ring a bell.
>
>
> > 6. WHERE IT STANDS
> > ==================
> > At stock max_perf on DC: 13 deaths in 14 valid arms
> > At smax <= 3800000 on DC: 43 ladder steps + a 35-min mixed soak + a 20-min integrity soak, 0 deaths
> >
> > Nothing has moved that gate: BIOS 01.22, BIOS 01.25, EPP, governor, min_perf pinning, CC6 off, and three kernels. Only the frequency cap does.
> >
> > I also built a self-verifying canary (bit-exact AVX2 checksum, single-bit-flip selftest 60/60) and ran four instances on the CPPC preferred cores alongside
> > the real workload, on battery under the cap, for 20 minutes: ~557,000 verified passes, ~17 TiB checked bit-exactly, zero compute errors, zero memory
> > corruption, zero faults, zero MCEs, no reset. Caveat: those canaries held their cores at sustained 100%, which does not produce the idle->boost transition
> > where section 3 puts the excursions, so that result does not yet cover the excursion case.
> >
> > Still happy to run anything you want on this machine - it reproduces in 10-50 s on demand, and I have per-crash triage, CPPC-counter frequency distributions and 5 ms RAPL/hwmon sample sets for every arm.
>
> Thanks a ton for all the data. After a boot, could you share the data
> from running:
>
>   grep -r . /sys/devices/system/cpu/cpu0/acpi_cppc/
>   grep -r . /sys/devices/system/cpu/cpu0/cpufreq
>
> Also, does this issue reproduce if you add "amd_pstate=disable" in your
> kernel cmdline, reboot into same kernel, and run the benchmark?
>
> You'll have the acpi-cpufreq driver running which does _PST P-states
> based scaling but the boost frequencies are completely controlled by
> SMU firmware still.
>
> It will help narrow down if a specific CPPC path triggers it for out
> SMU folks.
>
> Note: You'll need to do a full reboot and not a kexec since some bits
> of CPPC based scaling cannot be disabled without a full reset.
>
> Thanks a ton again for all the data.
>
> --
> Thanks and Regards,
> Prateek
>