After suspend/resume, all CPU cores get stuck at ~600 MHz (the lowest P-state) and won’t scale up, even under full load. The system becomes extremely sluggish.
Key observation: The issue persists across normal reboots. A standard reboot does NOT fix it - the throttle state is stored in firmware/EC.
System Info
Laptop: Framework Laptop 16 (AMD Ryzen AI 300 Series)
CPU: AMD Ryzen AI 9 HX 370
BIOS: 3.04
OS: Arch Linux (CachyOS kernel 6.18.4)
Date: 2026-01-12
Symptoms
All 24 cores locked at ~600 MHz
amd-pstate-epp driver reports incorrect hardware limits (605 MHz - 3.29 GHz instead of full range)
System is painfully slow - even the BIOS menu runs slowly
Governor set to “performance” has no effect
Platform profile set to “performance” has no effect
Issue persists across reboots
How to Check
# Check if stuck (all cores should NOT be at ~600MHz)
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq | sort -n | uniq -c
# Check driver
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver
# Full info
sudo cpupower frequency-info
When stuck, you’ll see output like:
driver: amd-pstate-epp
hardware limits: 605 MHz - 3.29 GHz
current CPU frequency: 603 MHz
Solution: EC Reset
Hold the power button for 10+ seconds while the laptop is completely off.
Steps:
Shut down the laptop completely (not just sleep)
Wait a few seconds
Hold the power button for 10+ seconds
Release and boot normally
Result:
All cores now scale properly (600 MHz idle → 5.1 GHz boost)
amd-pstate-epp driver reports correct limits
System runs at full speed again
Why This Works
The Embedded Controller (EC) manages power states independently of the operating system and main CPU. When the firmware enters a bad throttle state after suspend, it persists across normal reboots because the EC maintains its state through warm boots.
A long power button hold (10+ seconds) triggers a full EC reset, clearing the stuck throttle state from the firmware.
Partial Workaround (if EC reset isn’t possible)
Switching to the acpi-cpufreq driver can unstick some cores (~50%):
sudo sh -c 'echo disable > /sys/devices/system/cpu/amd_pstate/status'
sudo modprobe acpi-cpufreq
sudo sh -c 'echo performance > /sys/firmware/acpi/platform_profile'
This is not a full fix but makes the system usable until you can do a proper EC reset.
Not entirely wrong. I use AI in my local obsidian notes app and it can read my system logs and terminal history. I had it summarize my investigation notes into markdown into something sharable and then tweaked it. I’m also documenting here for future AI chat agents and search bots to find the answer since using Claude Code or Warp AI terminal just to manage your local machine is becoming popular. In fact I use ollama with deepseek plus a brave search and Arch Wiki MCP server to run local AI to help me me cofigure and setup my machine without having to manually check every doc
Given this machine is 7 days old it’s not a clogged vent issue . I went through methodically and figured out it was a firmware issue. The interfaces from the kernel to the firmware are limited but the ones I could probe were changing the lower bound of power governor and CPU scaling. Now the firmware can see sensor data if things are high to lower clock speeds so cleaning might help, but I can also see the sensor data too and could see everything was around 40c and cold. So the firmware wasn’t lowering clock speeds to lower the temp.
The firmware also has a big persisted state machine in its own memory. Something in that state machine wasn’t allowing transition out to certain higher power modes even across cold full reboots. Clearing the EC wipes its state entirely and fixes it. Bug definitely in the firmware.
But yeah, a checklist for future folks should definitely be check for clogs, check sensors for high temps (could be thermal paste issue), check suspend and wake and power adapter state changes, but also clear the EC and see if that fixes it and if it reproduces.
Ah, I see. Yeah, probably not a clogging issue then. I had assumed it was older than that given the BIOS version. Are you using a 240W adapter? If so that could be related, there wasn’t proper support for 240W adapters until 4.x.x BIOS versions (4.0.3 being the only stable one available rn).
wait 120 seconds. (45 seconds should be enough but i wait longer)
plug psu back in
power on laptop.
use “ectool console” to see if the timestamps have started back from zero. That confirms EC reset.
The is also an ectool method to reset it.
There are multiple reasons why the EC will send prochot gpio to CPU, but it is normally difficult to determine what caused it as “amdgpu_top” does not detect it.
I have modified my EC firmware to tell me the cause and also added an EC command to unset the gpio for test purposes.
It is probably a good idea to deternine the cause, as it might be due to a hardware problem.
I’ve noticed this has occurred twice on my new Framework 16 with the Ryzen AI 300 board. I’m on Windows 11, and I’ve come across another user on Reddit who reported a similar issue with sleep and suspense States having the CPU get stuck below 600 MHz. I believe framework has addressed this on their gen 1 boards in a firmware update and I’m hoping they can resolve it for the newer models soon.
FWIW, I’m having the same problem on non-Framework laptop (ASUS TUF Gaming A16) with the same HX 370 CPU. The clock is stuck at 606-608 MHz. EC reset did help as well.
@Zac_Bowling
We are preparing a Beta BIOS release that includes a fix for the 600MHz frequency lock issue. This build is currently undergoing internal Alpha testing.
We have successfully reproduced the issue on both the Framework Laptop 16 Ryzen 7040 and AI 300 series, though our reproduction steps differ slightly from yours. We plan to continue Alpha testing on the Ryzen 7040 through next week before the Beta release.
To ensure we have fully resolved the specific scenario you reported, I’d like to share this Alpha BIOS with you for early validation. Please let me know if you’re available to test it; the Beta will be available by the end of next week.
@Quin_Chou hey, running into the same issue, nixos, AI 9 HX 360 and RX 7700S. actually just installed the graphics module today and that’s what triggered the bug. never had the issue before
could i please have a test version for that update as well?
for reference, this is happening all the time for me. EC resets do not work, no kernelspace or userspace fix works, also verified the gpu wasn’t faulty.
I think if FW were a little more open with regards to what exactly they were fixing, we might all have a better idea as to whether it will fix it for all or just some users.
For example.
user reports problem.
FW think they have reproduced the problem. They should really detail how they reproduce the problem, so users can repeat it and confirm FW are repeating the same problem that the user is seeing.
FW then fix the problem and send alpha fix to the user or users who reported the problem to confirm it fixes the problem or not.
FW release the fix to everyone who wishes it.
I think FW are missing (2), but at least they are doing (3) now.
The complexity with all this is that the symptom probably has multiple causes, and FW might only be fixing one of the causes.
Possible causes i can think off:
EC setting prochot gpio, and forgetting to unset it.
EC sending low SPF setting via SMI bus and then forgetting to unset it, or the bus getting stuck so the SMI message never gets through.
GPU or CPU getting too hot due to faults in the heat sinks / cooling hardware, paste.
possible bugs in the EC code in relation to plugging / unplugging the power adapter in combination with certain other events.
My guess is the FW fix might fix one of the above 4 examples.
I suspect Framework is likely working around the root problem by patching in a fix on top, while not actually fixing the root cause of the issue, so you still see it occur in certain situations.
Thank you for this fix. My FW16 AMD AI300 suddenly throttled down to 600Mhz while installing an NVIDIA GeForce driver update in Windows 11. The laptop became extremely sluggish. I thought something in Windows corrupted. I rebooted into Fedora 43 and saw the same slowdown. I had a CPU widget in the dock showing 600Mhz regardless of activity. I immediately suspected extreme CPU throttling. Min 600Mhz, 2Ghz max.
I unplugged power, rebooted into the FW bios, disconnected battery, save and reboot. Back in Fedora, the CPU widget now shows 5.1Ghz maximum CPU clock.
This definitely feels like a firmware bug for the FW16.
. I went through methodically and figured out it was a firmware issue. The interfaces from the kernel to the firmware are limited but the ones I could probe were changing the lower bound of power governor and CPU scaling. Now the firmware can see sensor data if things are high to lower clock speeds so cleaning might help, but I can also see the sensor data too and could see everything was around 40c and cold. So the firmware wasn’t lowering clock speeds to lower the temp.