I’ve owned my Framework 13 for about two months now, and i’ve been experiencing this issue for as long as i’ve had it nearly. For context, i have the Ryzen 5 7640U model, with 32GB of Corsair Vengance 4800MHz CL40 DDR5 memory and i’m currently running Fedora Workstation 41 fully up-to-date.
Occasionally, after some uptime- and seemingly not coinciding remotely with any increased thermal activity or load- the CPU will downclock to 400MHz. This also seems to be regardless of OS install, installed applications, or anything of the like. This drop in performance renders it nearly unusable, and it takes great effort just to run a few commands for some troubleshooting results.
This presented about 6 days after i first got the memory i needed to set the laptop up, where i initially prescribed it as a failing NVMe drive since i had cannibalised an ADATA 1tb drive, and i was fully aware ADATA has horrendous fail rates and i hadnt troubleshot it further- i simply replaced the drive with a 512gb drive that i had already used in my previous laptop extensively that i knew had nowhere near surpassed its TBW rating.
It took about two weeks for the issue to pop up again, but when it did, it did so consistently within about an hour and a half or less of uptime, and this was when i decided to troubleshoot more. My first hunches were thermal throttling, so i tried to check the temps which i failed to do through linux [but only because i can’t read; i’m fairly confident i’ve actually got them just fine. see attachments.] and the power draw for the components [if it was possible at all], but what i DID find was that running
$ cat /proc/cpuinfo | grep “MHz”
after it entered its unstable state gave me a shocking revelation; most of the CPU cores save for 4 of them had downclocked to exactly 400.000MHz clean, one to 500-ish MHz, the rest to 1500-1600MHz and only one to about 4000-ish MHz. This result has been consistent, every single time, across three installs of Fedora, and one install of Debian.
It seems to be more random now, sometimes taking up to several hours of uptime to kick in [it just did it at about 4 hours]. It also just takes breaks for… however long, sometimes days, where it does nothing. However i can’t seem to tell if that’s the issue being ‘temporarily fixed’ by something i tried, or if it’s just decided not to replicate.
I have contacted Framework support, and i do have steps to continue troubleshooting this going forward, but i figured some community input as to why it might be downclocking certainly couldn’t hurt. It’s not thermals, it’s not the Linux kernel, it’s not my applications, it’s not my drivers, it’s not specific uptime… I’m lost, honestly. For all i know this might just be an honest board or chip defect- and one that, though i thank their thoroughness, probably isn’t going to be solved by sending them pictures of my board for a visual check.
I plan on also troubleshooting the RAM, removing it one stick at a time and if possible replacing it with another/another two DDR5 SODIMM if i can find any. I’ll try to report back on that when i can test it. Might test Windows too, see if it somehow has an impact. [On that note if anyone can recommend me any decent software for monitoring this stuff on Windows, it would be greatly appreciated, any memory i have of that kind of diagnostic work on windows has long since been shot dead by Linux.]
