CPU max boost clamped to ~2.4 GHz after resume from sleep until reboot (SteamOS 3.8.14, Steam Deck LCD)

[godmarck]

System

• Steam Deck LCD, BIOS F7A0133
• SteamOS 3.8.14 (build 20260703.1), kernel 6.16.12-valve24.4-1-neptune-616
• amd-pstate-epp, active mode (default)

Symptom

After every resume from S3 sleep ("deep"), the whole system feels laggy until reboot.
Cause: CPU max boost is clamped. A pinned single-core busy loop
(taskset -c 2 sh -c 'while :; do :; done') reaches 3.5 GHz before sleep but only
~2.42 GHz after resume — reproducible on every sleep cycle, including
rtcwake -m mem -s 45 with the machine otherwise idle.

Not thermal or power related: 46 °C, plugged in and charging, GPU idle.

Software state after resume looks normal

• scaling_max_freq = 3501250, boost = 1
• governor powersave, EPP balance_performance on all 8 CPUs
  (i.e. [SteamOS 3.8 Beta] AMD EPP resets to "performance" on CPU1-7 after waking up from sleep #2383 does NOT reproduce here — the EPP fix from
  torvalds/linux@85d7dda5a9f6 appears present and working)
• ACPI CPPC still advertises highest_perf = 255, nominal_perf = 204

Things that do NOT restore boost (only reboot does)

• toggling /sys/devices/system/cpu/cpufreq/boost 0 → 1
• writing EPP performance to all CPUs
• performance governor
• re-writing scaling_max_freq
• amd_pstate mode switches, including a full disable → active driver reset
  (passive mode then caps at 2.8 GHz nominal, so the clamp appears to live in
  SMU/firmware state rather than driver sysfs state)

A second suspend/resume cycle occasionally restores full boost, but it is not reliable.

Related (but distinct symptom, already fixed): #2383

[godmarck]

Follow-up with significantly expanded findings — sleep is an aggravator, not a requirement. The clamp also develops progressively during normal awake use.

New observations (same system, fresh boot, monitored over ~2.5 h)

• Right after boot, every core boosts to 3.5 GHz.
• During normal desktop use (docked, KDE, no games), individual physical cores start getting parked at exactly ~2425 MHz under load — both SMT siblings of a core are affected together, and which core is parked changes over time. It appears to follow whichever core recently ran sustained load (e.g. kwin_wayland's home core).
• Verified with instruction-throughput benchmarks (not just scaling_cur_freq): a parked core does ~31% less work/s, matching 2425/3500. It is a real silicon slowdown.
• Sampling scaling_cur_freq every 5 s: the fraction of under-load samples stuck at 2425 MHz grew from 20% → ~40% over the first hour awake (no suspend), then jumped to 61% immediately after one suspend/resume cycle. After resume, all-core parking is persistent; only reboot restores clean behavior.
• Multi-core load still reaches normal all-core boost (~3.17 GHz) even while single-core boost is denied — so this is not a power/thermal budget limit (idle, 46–49 °C, AC power, slowPPT/fastPPT at 15 W).
• 2425 MHz looks like a fixed CCLK DPM step the SMU parks cores at and fails to release.

Ruled out

• EPP values intact on all 8 CPUs (balance_performance), so this is not [SteamOS 3.8 Beta] AMD EPP resets to "performance" on CPU1-7 after waking up from sleep #2383 (that fix is present and working)
• ACPI CPPC caps normal (highest_perf 255), boost=1, scaling_max_freq=3501250
• Per-core CCLK_RANGE in pp_od_clk_voltage unmodified (1400–3500 MHz)
• fclk/mclk ramp normally under load (not the 400 MHz VRAM issue); GPU sclk ramps normally; compositor on hardware GL
• No Decky/PowerTools or other third-party power tooling installed
• Not fixable from userspace: boost toggle, EPP rewrite, performance governor, scaling_max_freq rewrite, and full amd_pstate disable→active reset all have no effect; passive mode is also affected

Since it reproduces without any suspend involved, this looks like SMU/firmware CPU boost state degradation that the 6.16-valve kernel never resets — possibly the same class of issue as what was fixed for #2383 on the 6.18-based development kernel.

Happy to collect more data (debugfs dumps, specific sysfs traces) if useful.

[Franatix93]

This sounds like what I'm experiencing with the busy-wait fix in Metal Gear Solid 2. Gameplay locks at 2.4GHz and cutscenes lock at 3.5Ghz.
3.8.xx