12th Gen/Win 11 suddenly super slow

Sometime in the past week, my Framework went from running fine to running like molasses. You know the feeling, Explorer windows paint on
I’ve checked all the usual suspects - CPU and RAM utilization, free HD space, latest drivers, etc. Nothing has helped.

I’m now running Core Temp and am noticing that the CPU is rarely getting about 5.0 watts with the temperatures rarely hitting 50C.

I then ran Fan Control and set the fan speed to various numbers - 30%, 90% and everywhere in between and have not seen any changes.

And then it dawned on me…I don’t here the fan.

Could a dead fan be the cause of this problem? I would have thought that a dead would have allowed the CPU temps to climbs high before the CPU throttled itself down. But maybe the Framework throttles itself when it can’t turn the fan on?

I have ordered a new fan. Hopefully that will fix things. But could there be something that I’m not getting?

All help appreciated…

When starting your laptop from a cold boot are you seeing any kind of led pattern code? (green, green, red, etc.) A system fan not working would definitely be report on startup through an led pattern

You can try running the laptop with the top cover removed. See if the fan is spinning.
It may also be the infamous Intel 400MHz bug that can be fixed with a CMOS reset I believe?

4 Likes

No, I have not seen any LED pattern code, but maybe that’s because I’ve been walking away for coffee. Will check next time. Thanks.

Oh @Shiroudan I just checked Task Manager… 0.4 Ghz!!! This is the first that I’ve heard of this bug. Thanks for pointing it out. Will need to research how to fix.

Heya!
Here are some community threads regarding this problem, I believe there’s solutions in them! This Intel bug has been around for a while so it’s pretty well documented!

4 Likes

So the oddest thing has happened. As I mentioned last week, my CPU was stuck at 0.4 Ghz, which was great for battery life but awful for productivity.

On Saturday, I unplugged the Framework and stuck it in my backpack. I was going away and always pack it in case something come up.

I didn’t use it Saturday.

On Sunday evening, I was back home and pulled the laptop out to start researching how to address this issue. And when I turned on the laptop - unplugged - it was back to normal! The CPU was working normally and the fan was turning on as needed.

It’s Monday afternoon now and the laptop continues to function properly. The only thing I can surmise is that the laptop had been plugged in for at least a week and somehow 36 hours of it being unplugged and in hibernate mode magically unstuck it!

I hope that the Framework team is monitoring this and that it helps them identify what the root cause is.

Thanks again @Shiroudan for your help.

1 Like

Just another data point - my Framework Chromebook does this any time it is charging below 80%. So far I have just made sure I am always fully charged and my work schedule doesn’t require me to unplug often. It can be super annoying when you’re pegged at 400 MHz though.

1 Like

Another way to quickly solve the issue is by going to the BIOS and doing a Battery Disconnect, shutting off the Framework, unplug any cable, and boot as normal.

3 Likes

Is this a permanent fix that is done once, or just to avoid the throttling issue if it comes up?

1 Like

nope its a bios bug most likely

2 Likes

Update: This issue still happens from time to time, about once a month, and typically after the laptop has been plugged in for several consecutive days. The solution - unplug and reboot - still works.

I do wonder if this fix will cease to work someday…

One should wonder when / if there’ll ever be a fix for this at all, not the temporary workaround.

Had the same happening to my laptop (Gen 12, i7, Win11) over the weekend. Discharging battery helped to resolve it. So far, haven’t had this issue again.

Just ran into this myself. Laptop was running a game at as fast as it could for a few hours, then I started hearing the audio break up with massive frame loss. Checked task manager, 0.4GHz and no audible fan. After a few minutes the fan spooled itself back up, only to come down again some time later. Laptop was at 100% battery, plugged in, and sitting on a flat hard surface.

Seems like it might be a firmware? fan control issue since I don’t have any applications running (that I know of) that can take control of the fan.

If there’s any kind of profiling I can run to help troubleshoot let me know, I’m willing to help where I can to chase it down.

Win 11 22635.2771
i7-1260P DIY
16GB

A post was merged into an existing topic: Clock stuck at .39Ghz

Our company has a fleet of these Frameworks, and we’ve suddenly had this issue on 4 of them in the last 2 weeks. Just FYI, installing this bios update immediately resolved the issue for all 4 of them:

https://downloads.frame.work/bios/Framework_Laptop_12th_Gen_Intel_Core_BIOS__3.08b.msi

NOTE: All the laptops are running Windows 11 Pro. 3 of them gave an error immediately after running the .msi file that the update could not complete, however rebooting Windows did in fact complete the update, and the issue was resolved.

3 Likes

I also experienced this bug just now on FreeBSD 14.1-STABLE stable/14-n268491-09d61b28a00a GENERIC amd64 on 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz (2995.20-MHz K8-class CPU) after I upgraded several parts, including my 55 Wh battery to 61 Wh battery. I was already on BIOS 3.20 when this happened. Doing your suggestion fixed my issue. Thank you!

We can see the before and after speeds:

sysctl -a | grep dev.cpu.[0-9] | grep freq: | sort -n

Before
--------
dev.cpu.0.freq: 398
dev.cpu.1.freq: 398
dev.cpu.2.freq: 398
dev.cpu.3.freq: 398
dev.cpu.4.freq: 398
dev.cpu.5.freq: 398
dev.cpu.6.freq: 398
dev.cpu.7.freq: 398

After
-------
dev.cpu.0.freq: 2492
dev.cpu.1.freq: 2839
dev.cpu.2.freq: 2549
dev.cpu.3.freq: 2839
dev.cpu.4.freq: 2609
dev.cpu.5.freq: 2833
dev.cpu.6.freq: 3238
dev.cpu.7.freq: 2692
2 Likes

Posting a minor upgrade, I’ve noticed that if the computer is pushed for an extended period of time (in a way that generates heat - like during my 24-48 hour compilation of ports compilation upgrades on FreeBSD) or if I switch between Linux and FreeBSD as well (not 100% confirmed but I’ve noticed the behavior here as well), the 400 MHz bug will happen. The bug will happen during system operation, meaning that your computer can boot up perfectly fine, but if it encounters this bug, it will slowdown and stay there permanently (until you do a battery disconnect in BIOS). If you don’t do a battery disconnect, it will permanently stick across reboots.

1 Like