System:
Intel i5-1135G7 Batch 4
Original Charger
Framework Laptop Driver Bundle
It is a repeatable problem. CPU will locked in 0.39Ghz~0.4Ghz when battery charge to 70%~80%. It has been verified that different Windows systems, solid state drives, external monitors, and external devices will not affect the results. Here are some graph of recent recording by HWiNFO.
10 Minutes Around:
3 Minutes Around:
Full Length:
I just wanted to chime in as well that I’m experiencing this issue. Framework batch #3, using framework charger, running Ubuntu 21.04
I get forced down to 400mhz on all cores while charging and it slowly floats up as the battery becomes more charged. Right now I’m at 95% charged (plugged in) and 2.4Ghz.
Is there any more info about this issue?
I wonder if this is a hardware or a software issue that can be fixed via a BIOS update.
In either case, sounds like @Framework team is looking into it. I am sure they have reached out to Intel for comment as this is impacting a A LOT of the users.
I don’t have the data, but I can say that my 1185G7 behaves exactly the same, and it is very reproducible.
My battery finally dropped below ~65% so I plugged it in. With both the Framework charger and a brand new Anker 60W charger, once the charge level hit 70%, the CPU is pinned at 0.39 GHz. So, reseating the EMI stickers did not help in my case.
Just chiming in to say I have this issue too on a Batch 4 1185G7 - but only when using an Anker PowerPort Atom PD 4 (which will allegedly charge at 100W). Using a PinePower (which only delivers 65W on a single port), I am unable to reproduce it.
Using a USB-PD tester, I observe my laptop drawing only ~55W (19.1V, 2.9A) from the Atom PD4 (not the full 100W- so it seems unlikely that 100W just being available would change anything).
echo "1" > /sys/module/processor/parameters/ignore_ppc doesn’t seem to change anything.
Throttling begins around 80-83%, and seems to get less severe (clocks rise to 600-800MHz) around 87%, with clocks continuing to rise slowly from there - at 89% I see about 1500Mhz, 90% around 1800MHz, 93% around 2400MHz, 95% around 2700MHZ,
Disabling BD_PROCHOT with the steps at https://github.com/DivyanshuVerma/throttlestop-linux immediately stops the throttling and the laptop returns to normal clocks. Re-enabling it (restoring the original MSR 0x1FC value) immediately restarts throttling (when the battery is still in the “evil” range). This is entirely reproducible and reliable, as far as I can tell- but I’m wary of actually using it as a workaround (since, while unlikely, maybe something actually is overheating somehow!)
One thing I notice that could be significant- according to my cheap USB-PD tester, the Atom 4 charger (which triggers this throttling) is providing around 19.1V at the laptop end of the USB-C cable and 19.5V at the charger end. The PinePower, which does not trigger this throttling, is providing a solid 20.0-20.1V at the laptop end and 20.3V at the charger.
Maybe the laptop thinks it’s drawing too much power from the charger (because of the voltage drop) and is throttling to match?
After doing a bit more testing, doesn’t seem as simple as my last post, unfortunately. Found a third charger, from which the laptop currently (at 94% charge) draws ~2.2A at 19.2V (measured at laptop side); it does not trigger throttling. When connected to the PowerPort Atom, which triggers throttling, at 94% charge, the laptop draws ~1.8-1.9A at 19.4V, yet still throttles (to around 3.2GHz v.s. ~4.5GHz on cpu0 when running taskset 1 stress -c 1 (i.e. single-threaded load pinned to CPU0)).
I can just watch the laptop’s CPU frequency (watch -n 0.1 cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq) and swap between the two chargers: plug in the PinePower or the third (unbranded) charger, see the CPU frequency quickly stabilize at 4.5-4.6GHz. Unplug, CPU frequency drops (due to TLP changing the governor to powersave, this shouldn’t matter); plug the Atom PD4 in, CPU frequency also quickly stabilizes at ~4.5GHz for just a second and then drops to something closer to 3.5GHz.
Swapping cables between the two chargers had no effect.
Next theory: EMI. Unfortunately, my good RF equipment isn’t accessible right now, but I have a 200MHz scope, so I put that on a test point on my USB-C tester (which is connected directly to Vbus; the tester was on the laptop side for all of these) to take a look at noise.
Here’s the Atom PD4 (triggers throttling) v.s. the PinePower (doesn’t)-
Atom PD4
PinePower
Nothing obviously sticks out, as far as I can tell (but I’m no engineer); though the Atom does seem to have more RMS noise power…
Attaching a ferrite bead to the USB-C cable did not affect the throttling behavior.
If there’s EMI going on, it seems as though it’d have to be internal- not as simple as just a noisy adapter. But then why can one adapter trigger it and another not? Very strange.
[Batch 4, i5 DIY] I consistently reproduce this with the Framework charger, but couldn’t reproduce it the three times I used my friends’ chargers (Macbook Pro chargers ?? W, Dell XPS charger 45 W). I don’t have any data to back this up though. I haven’t fiddled with the EMI shielding stickers yet.
I’d been experiencing this issue on my machine (batch 2) as well: I was throttling down to 0.18GHz, initially only occasionally, eventually all the time, even when on battery power. Fixing the EMI shielding stickers appears to have fixed this for me (3/4 were not properly seated).
One thing worth noting: I got the DIY edition, and I had clearly damaged / unseated one of the stickers while installing the wifi antenna. It might be worth mentioning the stickers in the wifi step of the setup guide? I had not even realized they were there or could be a problem at the time.
Can confirm I’m seeing this, machine started to chug while charging at around 50ish percent, it has continued to around 80 percent. I can unplug my charger and the performance immediate jumps right back to normal.
I’m running Arch w/ GNOME, there’s a power settings toggle in the top right and I have it set to “performance” but I have no clue if that actually does anything.
Hello, everyone,
To keep everything a bit more organized and ensure we have as much data as possible to research this current issue, please DM or email me at Bee@frame.work with any additional information you can provide. This can include OS, order number, batch number, power adapter, or anything else you feel is helpful to get us one step closer to targetting a solution!
Moving forward, before taking any troubleshooting steps, we ask that you please create a ticket via Framework | Support so we can assist you with troubleshooting and ensure that all steps taken are noted to see what does and doesn’t work! Upon doing so, please feel free to send me an email or DM with your ticket information so we can keep a close eye on that as well!
Thank you, and please let us know if you have any questions! 
An update for everyone in the thread. We think we have identified the cause and are validating a firmware fix. We are targetting a fix for this in bios 3.07 Which we plan to release in the next 10 days.
I’m very curious what the cause of the issue is, I hope you can share it (even if it’s technical) at some point.
That’s great news! I haven’t personally noticed this problem, but it’s something people have been dealing with for a while and it’s good to know it may soon be fixed.
Definitely great news after trying the other workarounds like reseating the EMI stickers (or in my case I ended up ripping them off completely) and trying different chargers.
If you are experiencing this issue (400mhz, 0.39ghz cpu clock) while charging the battery above around 50+% and want an early test build based on 3.06 that has a fix, DM me on the forum and I can provide a link to download. Otherwise we will be releasing 3.07 in the next week or so.
Technical reason seems to be related to some component variation around the charging circuit. Internally the charger IC has several control loops that run, including an input current control loop, and a battery charging control loop. Both of these limit current, and the input current loop can also limit the battery charging control loop. At a high state of charge the battery charging control loop can allow the input current to increase to the maximum input current, and trip the prochot over a very short time interval before correcting, (microseconds) due to what I think is control lag. The charger has a setting to debounce this, and we increased the debounce time. Still getting some data on the exactly why this happens, but this sounds like a case where a pole moved to the right hand side of the plane 
@Kieran_Levin, just to confirm, will this be installable for users with Linux right away? I think I remember the existing bios updates were only installable from Windows.
Much appreciate the update, but I believe most of us would like to wait for a stable release.
Agreed, would be nice to have the ability to flash it via a bootable media.
So far, it seems to be working for me. I have tested on all 4 expansion ports. Previously, every time I charged with a particular charger and reached ~80%, the CPU throttled to 0.39GHz. Now I seem to notice no performance issues.
Thanks, @Kieran_Levin!
