Just had a situation where after resume from standby, the CPU (AMD 7840U) was stuck in a very low-speed state (0.5 GHz) rendering the system extremely sluggish. A reboot resolved the issue but seems indicative of a driver/firmware/BIOS issue.
1 Like
I have seen this on my 7640U using linux with the old BIOS 3.02 but not since the upgrade to BIOS 3.03. Are you on the current BIOS version?
I’m running into this as well: AMD 7840U (6th batch), bios at 3.03, running NixOS, Kernel 6.1.69. (Edit: Looks like this old kernel was the problem for me.)
Power profile/governor set to power-saver, but no change if I set it to performance. Great for battery life, though!
$ cpupower frequency-info
analyzing CPU 0:
driver: amd-pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 20.0 us
hardware limits: 400 MHz - 5.29 GHz
available cpufreq governors: powersave performance schedutil
current policy: frequency should be within 400 MHz and 5.29 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 546 MHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: yes
AMD PSTATE Highest Performance: 202. Maximum Frequency: 5.29 GHz.
AMD PSTATE Nominal Performance: 126. Nominal Frequency: 3.30 GHz.
AMD PSTATE Lowest Non-linear Performance: 42. Lowest Non-linear Frequency: 1.10 GHz.
AMD PSTATE Lowest Performance: 16. Lowest Frequency: 400 MHz.
$ cat /proc/cpuinfo | grep "cpu MHz"
cpu MHz : 540.212
cpu MHz : 400.000
cpu MHz : 540.895
cpu MHz : 400.000
cpu MHz : 548.836
cpu MHz : 548.298
cpu MHz : 400.000
cpu MHz : 549.028
cpu MHz : 539.352
cpu MHz : 400.000
cpu MHz : 548.172
cpu MHz : 548.992
cpu MHz : 546.360
cpu MHz : 547.823
cpu MHz : 539.509
cpu MHz : 539.374
(Please excuse the edits, there was a bug in discourse forum software that was preventing me from submitting some text, weird.)
I rubber-ducked myself to victory! Noticed that I was running a fairly old kernel, updated to 6.6.8 and now everything is fine again.
1 Like
I am also observing this on Opensuse Tumbleweed, on the latest kernel (6.6.11-1-default). All cores are stuck at a maximum of 544 MHz. To get the system unstuck (in Linux), I just found the workaround described here: [SOLVED] [FW 13 AMD 7840U] Did kernels >=6.6.7 make your system/touchpad/mouse laggy? - #12 by bikefrivolously
For easy reference here: To unlock the core frequencies, toggle the scaling governor like so
sudo cpupower frequency-set -g performance && sudo cpupower frequency-set -g powersave
EDIT: I’m also on Bios 3.03
Related kernel discussion: [Bug 218305] New: Ryzen 7 7840HS gets stuck at 544MHz frequency after a random number of suspend/resume cycles
1 Like
There is a kernel patch that looks promising: [PATCH] cpufreq/amd-pstate: Fix setting scaling max/min freq values - Mario Limonciello
I’ve tested it yesterday and today and can no longer reproduce the issue I was having where the CPU gets stuck at a low frequency after reboot.
It looks like right now it will be picked up for the 6.8 release candidates. I’m not very familiar with how this works but guess it might also end up in 6.7.x stable release before 6.8 is available.
1 Like
Have had this issue for some time. Today i upgraded my amd-ucode update on Fedora39 (amd-ucode-firmware-20240115-2) and have not been able to replicate this issue since …
I am hopefull 
It looks like the above patch made it into the 6.7.3 kernel. Fedora 39 is currently on 6.7.4. Between that and the new firmware, fingers crossed this is resolved.
Anyone still seeing it happen on the latest kernel?
I had this happen once with 6.7.3-arch1-1 (Arch Linux) on Feb 10. It definitely happened after some suspend and resume, and resolved itself after a few other suspends and resumes. PPD profile changes have not helped, I think I was on balanced_performance when this happened.
$ cpupower frequency-info
current CPU frequency: 544 MHz (asserted by call to kernel)
I rubber-ducked myself to victory! Noticed that I was running a fairly old kernel, updated to 6.6.8 and now everything is fine again.
I posted before that a newer kernel fixed it for me, but turns out it didn’t. It just didn’t happen for a few boots in a row, but occasionally still happens.
I’m on 6.7.2 now, still happening occasionally. Even on a fresh reboot, not just from suspend/resume.
If this happens to anyone again, can you please pay attention to the circumstances of your suspend? Did you start with a power adapter plugged in and then unplug it before waking up? Or start with one not plugged in and plug one in before waking up?
Furthermore if you did change the power adapter during the sleep state and this has happened; can you see if plugging/unplugging it a few times after you wake up helps?
Hi Mario. I’m not using a Framework laptop, but I have the same CPU and was experiencing the same issue. Unplugging and plugging the power adapter did solve the issue for me.
I’ll try experimenting a bit with plugging/unplugging the power adapter while the device is suspended to see if I can reproduce this.
Edit: I can reproduce the issue on Linux 6.8.6 with the following steps:
- Ensure that the power adapter is not plugged in
- Suspend the machine
- Wait for 10 seconds
- Plug in the power adapter
- Wait for 10 seconds
- Wake the machine
- The CPU frequency is now stuck at 544 MHz
When I unplug the power adapter now, the frequency will immediately start scaling up again. Replugging the power adapter again while the device is awake is also okay.
I was unable to reproduce the issue by starting with a power adapter plugged in and unplugging it before waking up. This did not seem to cause any issues.
2 Likes
What is your model laptop?
My laptop is a HP Elitebook 845 G10. We discussed a related issue a few weeks ago on the freedesktop gitlab. Should I open another issue on the amd/drm repository on gitlab and move our discussion there?
There’s a bug opened here for 845 G10. I believe it’s a bug in their EC.
218305 – Ryzen 7 7840HS gets stuck at 544MHz frequency after resuming after unplugging the power cord during sleep (kernel.org)
I’ll also post my findings in that bug report, that’s probably the more relevant place. It would be unfortunate if it’s a bug in their EC, as that might be less likely to get fixed.
My understanding of this is that many ECs will enact thermal throttling when the power adapter is removed. But most OEM’s EC is a black box and you won’t be able to know what they’re doing without reverse engineering.
In the case of Framework’s EC you can see places that throttle_ap() is called to tell what causes thermal throttling:
EmbeddedController/common/charge_state_v2.c at hx20-hx30 · FrameworkComputer/EmbeddedController (github.com)
But that’s also why I’m suggesting that if someone can reproduce this and you can get the EC log pulled up you might be able to tell exactly why Framework enacted throttling. In the case of other OEM’s systems; not so much.
1 Like
I just had the bug. I’m not 100% sure on the state when I suspended. I either unplugged it before or after suspending it. I’m pretty sure I plugged it before resuming.
I fixed it by unplugging and plugging the power adapter.
This is on Framework 13 AMD - Kubuntu 23.10 - Kernel 6.5.0-1023-oem
This is the cpupower frequency-info during the issue:
analyzing CPU 1:
driver: amd-pstate-epp
CPUs which run at the same hardware frequency: 1
CPUs which need to have their frequency coordinated by software: 1
maximum transition latency: Cannot determine or is not supported.
hardware limits: 400 MHz - 5.13 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 5.13 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 544 MHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: no
And after:
analyzing CPU 2:
driver: amd-pstate-epp
CPUs which run at the same hardware frequency: 2
CPUs which need to have their frequency coordinated by software: 2
maximum transition latency: Cannot determine or is not supported.
hardware limits: 400 MHz - 5.29 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within 400 MHz and 5.29 GHz.
The governor "powersave" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 3.16 GHz (asserted by call to kernel)
boost state support:
Supported: yes
Active: no