Ive had the problem of my CPU getting stuck at 0.5GHz after waking up from sleep mode, or simply booting. ive read other posts where the issue evidently stems from a BIOS problem, but im still having this problem on the newest BIOS. A restart often fixes it, but ive had times where i had to restart twice to fix it.
Windows version: Windows 11 Pro 25H2
BIOS version: 4.04
CPU: Ryzen 9 7940HS
RAM: 1x32Gb of framework DDR5 5600
dGPU: RX7700S
Yes this is still a problem. I leave mine on all day and by the end of the day it has locked its self down to the 544MHz every day without me even using it most the time, it’s just been on. Usually a sleep/wake cycle brings mine back to normal though.
I don’t know why Framework seems to have no interest in fixing this laptop. Sadly, it says a lot about the potential future of the company if they have no interest in fixing major problems like this. If these laptops were used by our company, they would all be going back due to this issue and the obvious neglect to fixing it.
Apparently, this problem only presents itself on sysyems with a dGPU.
There have been a number of causes, some have been fixed in the latest bios update. Obviously a cause still remains.
I am another user like you. But, if i was a manufacturer, i would prioritise investigations that might be hardware design problems. Reason being, that i can then fix the problem with the next mainboard release. I.e. if the problem is seen on a 7040 series mainboard, it would at least be fixed on then ai300 board.
Once the root cause is discovered, sometimes one can use software to mitigate it.
A recent bug fix went into the linux kernel that adds a small delay when waking from sleep. It now complies with the pcie standard. That is likely to improve behaviour when resuming after sleep/suspend. I don’t know if it will help the 544 problem, but it might.
Its the sort of bug fix where: it works in windows but not linux symptom is reported.
I have a FW16, but not a dGPU, so i have never seen your particular problem.
Yes it appears to be the case. I don’t think we ever see people without a dGPU reporting this issue.
They might be doing that internally, but I doubt they would tell us for fear of needing to recall them all.
I suspect it is caused by shenanigans they put in their power modes. They have actually stated they purposely drop it down to 544MHz (or trigger throttling flags) when changing certain power modes, a use I don’t believe is the proper use of the flags. In any case, it seems to happen to me when power states change (dgpu wake/sleep, battery charge limit changes, sleep/wake, etc).
Their near radio silence on trying to fix our laptops, and the super long times they take between updates (months in most cases), is getting ever more depressing.
Also note, i found an EC bug that could be contributing to this, but FW are just ignoring it.
Bug being, in some cases EC i2c writes silently fail, thus power control messages between EC and CPU get lost.
I have a EC source code bug fix, but FW don’t seem at all interested.
The CPU side is also a bit rubbish, because it i2c receive should be able to receive the i2c writes, even before my fix. So, my EC fix is more to work around the, possibly hardware, bug on the CPU side.