[Laptop 16 / 7040 / BIOS 4.05] CPU power budget drops to ~7W (all cores pinned at 544MHz), no suspend involved, only a reboot recovers

[bigcspecv]

System Model or SKU

AMD Ryzen 7040 (Framework Laptop 16, original pre-order unit, SKU FRAGACCP0J)

BIOS Version

4.05 (dated 06/30/2026)

DIY Edition Information

• CPU: Ryzen 9 7940HS (16 threads)
• Discrete GPU module: AMD Radeon RX 7700S (Navi 33, 1002:7480) — installed and in use
• RAM: 64 GB
• Storage: WD_BLACK SN770 2TB + WD_BLACK SN770M 1TB (both NVMe)

Port/Peripheral Information

• Charging over USB-C. The EC reports a negotiated 20V / 4.80A (96W) contract, and this stays correctly negotiated even while the fault is active.
• A DisplayLink dock and an external USB backup drive are connected.
• Battery charge limit set to 80% in BIOS (battery sits at ~79%, "Not charging").
• I could not reliably map the kernel's UCSI port index onto Framework's documented port numbering; happy to confirm the physical port if that would help.

Standalone Operation

Full system (complete laptop), standalone mode not enabled.

Describe the Bug

Intermittently, all 16 CPU threads become pinned at ~544 MHz and the package draws only ~7.2W. It never recovers on its own — only a reboot clears it.

This is likely related to #202, but two differences may help narrow the cause:

1. No suspend is involved. #202 and the earlier community reports frame this as a post-resume problem. Suspend is disabled on this system, and the journal confirms PM: suspend entry occurred zero times in every affected boot. Resume is not required to trigger it.

2. This looks like a power-budget delivery failure, not a frequency lock. Under a full 16-thread load the package draws 7.34W at 46°C. Framed that way, the SMU is behaving correctly for a ~7W budget, and 544 MHz is simply the fastest the silicon runs inside it. The question is why the SMU is handed ~7W instead of the expected ~45W.

Evidence that the constraint is the budget rather than any limit register: running ryzenadj --stapm-limit=45000 --slow-limit=45000 --fast-limit=60000 succeeds (rc=0, all three report "Successfully set") and the clamp does not move — still 544 MHz / 7.2W. The SMU accepts higher limits and still delivers 7.2W, so whatever reports available power sits upstream of those registers.

Ruled out by measurement, not assumption:

Suspect	Measured	Verdict
Thermal	Tctl 46–50°C during the fault; fans reach ~4300 RPM when healthy	not it
cpufreq	governor performance, EPP performance, boost 1, scaling_max_freq 5263061	OS is asking for full performance
ACPI throttling	all 16 cooling_device*/cur_state = 0	not it
Power supply	96W contract negotiated and active throughout	not it

Notably the cores run at 544 MHz — below the driver's own scaling_min_freq of 1100947 — confirming the clamp sits below the OS.

Steps To Reproduce

I don't have a deterministic trigger; it appears after some hours of normal use, on 3 of 4 recent boots.

1. Boot normally on AC power, dGPU installed, suspend disabled.
2. Use the machine normally for several hours (browser, video calls, terminal). No suspend, no hibernate, no lid close.
3. Periodically test achieved frequency under load — this distinction matters, as 544 MHz at idle is correct behaviour while 544 MHz under load is the fault:

for i in $(seq 1 8); do (timeout 5 bash -c 'while :; do :; done') & done; sleep 3
sensors | grep -m1 PPT
grep MHz /proc/cpuinfo | awk '{s+=$4} END {printf "avg=%.0f MHz\n", s/NR}'

Healthy: ~3300 MHz @ ~29W. Faulted: ~544 MHz @ ~7.2W.

4. Once faulted it persists indefinitely. Only a reboot restores it.

Observed across boots (dGPU transition counts via journalctl -b N | grep -c 'SMU is resumed successfully'):

Boot start	Duration	dGPU wake/sleep	Suspends	Faulted
2026-08-26 09:28	22h33m	32	0	yes
2026-08-27 08:02	4h41m	5	0	yes
2026-08-27 12:43	19h00m	9	0	no

I first suspected dGPU wake/sleep churn as the trigger, but the fault doesn't correlate with transition count — a 19h boot with 9 transitions stayed healthy while a 4h41m boot with 5 transitions faulted.

Expected Behavior

The CPU should retain its normal sustained power budget (~45W) for the whole uptime, delivering ~3300 MHz across all threads under load, without needing a reboot to restore it.

Operating System

Omarchy 4.0.1 (Arch Linux)

Linux Kernel Version

Linux fw-16-omarchy 7.1.9-arch1-2 #1 SMP PREEMPT_DYNAMIC Fri, 21 Aug 2026 22:18:59 +0000 x86_64 GNU/Linux

Additional Context

Recovery attempts, all tested against a live fault, all unsuccessful. Recording these so they needn't be re-tried:

Attempt	Result
Cycle governor / EPP / boost / platform_profile	no change (544 MHz)
ryzenadj raising STAPM / fast / slow limits	rc=0, "Successfully set", no change (544 MHz / 7.2W)
Wake the dGPU (power/control=on + DRI_PRIME=1), per #146	no change (544 MHz / 8.6W)
Unplug/replug charger to force PD renegotiation	no change (544 MHz / 8.7W)
Reboot	restores normal operation every time

The charger replug result is worth noting: I wondered whether the EC had fallen back to USB-C default source power, since 5V × 1.5A = 7.5W is close to the observed 7.2W. Forcing a renegotiation didn't clear the fault, so that doesn't appear to be the explanation.

---

Probably unrelated, but reporting in case it's useful. I noticed these while investigating and have no reason to think they're connected to the power-budget fault — no cooling device acts on them and they appear at every boot regardless of whether the fault later occurs:

• thermal_zone7 (acpitz) reports a constant 179.8°C
• thermal_zone4/5/6 report -0.2°C
• The kernel logs ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000) four times at every boot

Flagging them only because they look like genuine ACPI table errors on 4.05 that you may want to know about independently.

---

Separately, I can confirm the behaviour in #146 on BIOS 4.05: with the dGPU in D3cold the CPU is limited well below its rating. That's a distinct issue from this one — this fault clamps to ~7W, far below #146's 35W.

Related: #202 (same 544 MHz symptom, BIOS 4.03, attributed to resume), #146.