Skip to main content

CPU Frequency Lock (545MHz / 600MHz / 400MHz)

Summary​

A long-standing issue where CPU cores lock to an extremely low frequency — 545 MHz on FW16 AMD Ryzen 7040, ~600 MHz on FW16 AMD Ryzen AI 300, and 400 MHz on FW13 Intel 12th/13th Gen — making the system unbearably sluggish. The issue persists across normal reboots because the EC (Embedded Controller) retains the erroneous state. Only a full EC reset (holding the power button for 10+ seconds while powered off, or disconnecting the battery) clears it. Framework officially lists this as a Known Issue in BIOS release notes but has been unable to reliably reproduce or fix it after 2+ years123.

Symptoms​

  • All CPU cores lock to a fixed low frequency (545 MHz, 600 MHz, or 400 MHz depending on model)124
  • BIOS menu itself runs slowly — scrolling and navigation is visibly laggy1
  • System is effectively unusable for any task
  • Issue persists across normal reboots (warm boots do not clear it)1
  • On FW16 AMD: most commonly triggered after S3/Modern Standby resume, especially with a dGPU installed12
  • On FW13 Intel: triggered by BD PROCHOT (Bi-Directional Processor Hot) false assertion — a hardware/firmware bug where an external thermal signal incorrectly forces maximum throttling4
  • Fans may run high without corresponding CPU load before the throttle kicks in (Intel variant)4

Affected Models​

  • Framework Laptop 16 (AMD Ryzen 7040 Series) — most commonly reported, especially with dGPU12
  • Framework Laptop 16 (AMD Ryzen AI 300 Series) — CPU locks to ~600 MHz3
  • Framework Laptop 13 (12th Gen Intel) — i7-1280P, i5 variants; CPU locks to 400 MHz4
  • Framework Laptop 13 (13th Gen Intel) — i7-1370P; CPU locks to 400 MHz4

Root Cause​

There are two distinct root causes depending on platform:

AMD variant (FW16 — 545 MHz / 600 MHz)​

The EC enters an erroneous power state during sleep/wake transitions. The amd_pstate driver receives an incorrectly low frequency limit from the EC/firmware and enforces it. The state survives normal reboots because the EC retains its state across warm boots. Framework states they cannot reliably reproduce the issue and have been investigating for over 2 years12.

Triggers include:

  • S3 or Modern Standby resume1
  • dGPU wake/sleep transitions (most reports involve a dGPU)12
  • Battery charge limit changes2
  • Plugging/unplugging charger1

Intel variant (FW13 — 400 MHz)​

A false BD PROCHOT (Bi-Directional Processor Hot) signal is asserted by the EC or a peripheral, causing the CPU to engage maximum thermal throttling. BD PROCHOT is an external thermal trip signal — when asserted, the CPU immediately drops to its lowest frequency regardless of actual temperature. Framework staff confirmed there are "multiple causes" and some have been resolved in BIOS updates, but the issue persists for some users4.

Diagnosis​

  1. Check current CPU frequency:

    watch -n1 "cat /proc/cpuinfo | grep MHz"

    If all cores show ~400, ~545, or ~600 MHz consistently, this issue is likely present.

  2. Check for BD PROCHOT (Intel models):

    sudo apt install linux-tools-common
    sudo turbostat --quiet --show CPU,Bzy_MHz,IRQ,Bd_Prc_Hot  sleep 5

    If Bd_Prc_Hot shows 1, the external thermal signal is being falsely asserted4.

  3. Check amd_pstate status (AMD models):

    cat /sys/devices/system/cpu/amd_pstate/status
    cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq

    If scaling_max_freq shows an abnormally low value, the EC/firmware is feeding incorrect limits.

  4. Verify the issue persists across reboot: If a normal reboot does NOT fix it, but a 10+ second power button hold (EC reset) does, this confirms the EC state issue.

Workarounds & Fixes​

SolutionEffectivenessNotes
EC reset (hold power button 10+ sec while powered off)1Most reliable fixShut down completely, hold power button for 10+ seconds. Alternatively, disconnect battery in BIOS ("Disconnect Battery" option) or remove AC + wait 120s for EC capacitor drain
Switch to acpi-cpufreq driver (AMD)3Partial workaroundecho disable > /sys/devices/system/cpu/amd_pstate/status then modprobe acpi-cpufreq. Reverts to older frequency driver, may bypass the EC-fed limits
processor.ignore_ppc=1 kernel parameter (AMD)3PartialIgnores platform power limits fed by EC. May reduce frequency control precision
Disable BD PROCHOT via throttled (Intel)4Effective for Intel variantInstall throttled and set BD_PROCHOT: false in config. Requires root
Use s2idle instead of deep sleep (AMD)1Reduces frequencyAvoids S3 sleep transitions that trigger the bug. May not fully prevent it
Reboot (warm)1Sometimes works temporarilyOften does NOT clear the issue, as EC state persists across warm boots

Resolution​

No permanent fix exists. Framework has listed this as a Known Issue across multiple BIOS releases (4.04, 4.05 for FW16 7040; 3.04+ for FW16 AI 300)12. BIOS 4.04 partially fixed the battery-saver-mode variant (where low battery caused the 545 MHz lock), but the resume variant remains unfixed as of BIOS 4.05 (July 15, 2026)1.

Framework states they cannot reliably reproduce the issue internally, which has prevented a definitive fix. The community has reported it for over 2 years on the FW16 7040, and it continues to affect users daily12.

For the Intel variant, Framework staff indicated "multiple causes" exist, some of which have been resolved in BIOS updates, but the BD PROCHOT false assertion persists for some users4.

Footnotes​

  1. Framework Laptop 16 (Ryzen 7040) BIOS 4.05 Release STABLE — Framework Community (Jul 15, 2026) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16

  2. FW 16 7040 CPU stuck at 0.5GHz even after newest BIOS update (4.04) — Framework Community (Jul 8, 2026) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  3. CPU Frequency Stuck at 600 MHz — Framework Community (Jan 13, 2026) ↩ ↩2 ↩3 ↩4

  4. Framework 400MHz issue — Framework Community (Aug 5, 2026) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9