Makes sense. Thanks for the overview!
I have this issue using Linux 6.17.9. After resume, the clock goes up to max when doing light work, but when taxing the cpu, the frequency drops to the 900âs. This is with power plug plugged in.
What seems to work is running the power-profiles-daemon. https://gitlab.freedesktop.org/upower/power-profiles-daemon
When I get into the âstuckâ state and restart the daemon, the system seems to behave normally again. sudo sytemctl restart power-profiles-daemon
I have just updated to the latest system firmware / bios: IFGP6.04.03 / lotus-4.0.3.
Iâll see how it goes and report here if the latest firmware brings any improvement.
This sounds like the issue here:
Check the max watts your CPU is allowed when you stress it. I suspect itâs 35w. If so, please add a comment to that issue. Framework does not want to fix it.
Framework does not want to fix it.
Why do you say that?
They just fixed a similar issue (CPU stuck on 35W even without a dGPU) on the previous BIOS release. Not sure why assume they would not want to fix remaining bugs.
That is frustration speaking, obviously. But to clarify, this machine has had these issues well over a year and a half and in that time Framework havenât hired someone knowledgeable enough to fix these issues.
I do not have a Framework laptop, but I do have an Asus too with an AMD AI 370hx cpu, and I found a problem that could be similar to the one here. I usually create my own âpowersaveâ and âperformanceâ scripts, because I apply custom frequencies in hybrid CPUs like mine and perform undervolting too. I realized that this CPU has a problem when we set the âboostâ property to âfalseâ , because if my laptop suspends while âboostâ is disabled and I wake up the laptop again, after that, even if I set the performance governor again and enable the âboostâ, the laptop never goes up to the supposed allowed frequencies. In my CPU, when disable the âboostâ, this avoids that the laptop goes up to 2hz of speed of every core, while with âboostâ enabled (or â1â as it is the value we set in the files), the CPU is able to go up to 5.1hz in the performance cores and up to 3.2 for the efficient cores. In other words, after suspending with boost disabled, the laptop gets stuck with 2hz on each core and I am not able to set 3.2 or 5.1 again, no matter what I do without rebooting the system.
Currently I found a workaround for this situation, which is not setting the âboostâ as disabled in my scripts anymore, and just control the frequencies manually (same behavior of limitting the frequencies, but without using âboostâ property). So to summariez I kept the âboostâ value as â1â all the time, no matter the battery mode, and just set the limit the âfrequenciesâ for each Core/Thread when powermode. I have the same consumption in battery with that approach that the one I had when using âboostâ , and well, to be honest the real positive impact in battery and performance I have had, was after performing undervolting with ryzenadj (this is something that could take some time and not all the CPUs support, but when it works, the improvement in battery usage, performance and thermals can be huge in both modes: performance and battery ).
Location of the boost property is usually on: /sys/devices/system/cpu/cpu{coreNumber}/cpufreq/boost
Most of application that tries to control the CPU, like TLP, usually disable that property when powermode.
Ok, I seem to have lied. The firmware update did not improve things for me.
When power is plugged in the CPU can still end up in a stuck state. This happens after a sleep/wake event. A fresh restart resolves the stuck state.
This is annoying, since I like to put the machine to sleep and wake it up instead of powering it down completely. This seems like a basic piece of functionality that should just work?
Here is the zenmonitor3 for the system state in a stuck state with the power plugged in and under full load (heavy compile). As I do quite a lot of this, this stuck state is annoying to say the least.
I would love to get this resolved. How can I provide more data to help get this fixed?
Not a solution, but a workaround: limit battery charging to something less than 100% if you can.
At least here when I have it limited to 80% this issue never occurs. As soon as I disabled the limit and it was charging to 100%, it was back (on a previous BIOS, I havenât tested that with the latest BIOS).
I already have that on the âpower is mostly plugged inâ bios setting. I blieve that will charge to 60% or something. So that did not solve it.
I think the EC starts some power save modes at or below 60% charge.
It is probably better to set the limit to 80%.
Good luck getting them to listen to youâŚ.this has been a problem on the 16 since at least the bios version they added the battery save optionsâŚâŚi really wish i could go back to the original bios version that just worked (of course, itâs been a long time, maybe there were bugs in that version too that I donât remember).
Which power adaptor is this? I can get this to happen quite frequently on the SteamDeck EU power connector but rarely (if ever) on my UGREEN GaN ones.
I use a 240 Watt that came with the laptop.