Remember that each of 2 of the ports are on 1 controller. So the good one shares a controller with a “not correct” one.
I’d make sure that all the stickers are on properly just in case. Basically to nibble away at the possibilities.
First thing I did was get the stickers all correct on my machine (batch 2 as well) as it gave me a “you could get better bandwidth on another port” when I first started to put in modules. Msg went away before I had even started to read the whole thing…
I have also been having this issue with my new Batch 4 laptop (DIY running Pop! OS).
I was not able to charge using the rear left port, but using USB accessories worked fine in the same location. The laptop was generally working fine so I disregarded that as a fluke.
I noticed that if I powered it on without being plugged in, the CPU would be stuck at 200Mhz. Plugging in power would fix it. Also, removing the expansion card in the problem port would also cause the CPU to get stuck to 200Mhz. In that case, removing power would also fix it.
Tonight I followed the instructions to remove and re-apply the EMI sticker on the problem port. This seems to have resolved the issue for me. No more 200Mhz and I can also charge from that port now.
A quick update. After rereading this thread, I decided to follow the steps done by everyone else
Readjusting EMI Stickers
This had no effect on my Batch 4 laptop
Trying different module locations
Gathering data on the battery
My battery is also at 95% health which is inline to a majority of people in this post. Like what some other people have said, charging the laptop from 0-80ish % had no such throttling issues. However, from 84%-90%, I started lagging. For some reason, the issue disappeared once I charged the laptop past the 90% threshold. I will need to mess around with this a bit more to see if it is consistent.
Some other interesting points
As I was turning on the laptop from a suspend state, I noticed that s-tui was displaying the CPU running at a normal clock speed before getting stuck at 400mhz again after a few seconds.
Also, side note, I am not using Framework’s charger. Instead, I’m using RAVPower’s GaN 61w charger. Works perfectly fine on my previous T480.
Now at 90+%, I’m experiencing an interesting issue. Unplugged, my cpu can turbo up to its rated speed. However, on AC, I can only reach 1.2 GHz
I can now also confirm that I also experience a different reaction on clock speed when the AC adapter is online but not charging vs charging. No issues when online but not charging.
Manually disabling BD PROCHOT allows the system to return to base clock. Total package power reported by turbostat is only 15 watts however. In this case, it seems like the 28w sustained turbo is not occuring
What BD PROCHOT specifically is (from that github link above):
“BD PROCHOT" stands for bi-directional prochot. PROCHOT stands for processor hot. This signal is what initiates thermal throttling so the CPU can slow down and keep from over heating.
BD PROCHOT can cause CPU run at a very low frequency, on ThinkPad E440, which is only 800MHz(max 2.3GHz). The cause of the signal activation usually are aging power adapter, aging battery, or bad sensor on motherboard. Each of cause can activate BD PROCHOT.
What I found with additional testing is that, while disabling BD PROCHOT does allow the CPU to clock up in speed, the whole package is limited to 15 watts as opposed to its typical 28 watt power draw. This causes the Intel Xe iGPU to cripple itself in performance as the CPU uses the rest of the power budget.
So what do you think the fix will be? Some have surmised that the power supply is the problem and a higher wattage supply worked for them. I am in batch 5 and wonder if I should cancel the power supply and purchase an aftermarket one.
I’ve yet to narrow down a hardware issue or a firmware issue.
I’m curious if BD PROCHOT is triggering due to some kind of overheating charging component. I do notice that some components are getting warm when charging but nothing alarming. Maybe it could also be a temperature probe issue?
If it is a charger power issue, I’m not sure why the issue only appears from charging from 80% and up. Below 80% and the laptop works fine on the charger.
This makes me think it could be a firmware issue too.
I think several of us have noticed it happens when the charging rate drops off. As others have mentioned some Microsoft Surface devices had this issue, a coupleexamples. Likely will be a firmware issue / fix.
Since this seems to be the thread for CPU throttling, here is my report:
After putting the laptop to sleep (unplugged) for a few hours and picking it back up, I immediately noticed that it didn’t feel as “snappy” as it did before. All 8 cores appeared to be switching back and forth between 0.2 and 2.8 GHz (but nothing in between).
FWIW, the battery was at about 72% before sleeping, and 65% when I woke it up about 3-4 hours later.
I tried rebooting and cold-booting, but neither helped. I also noticed that the time between pressing the power button and actually seeing Linux boot was unusually long, which suggests an issue with the firmware rather than the OS power management stack.
In the end, I turned the laptop off and let it cool down for a half hour. Now it is back to its snappy self
All this to say, my experience has been consistent with the hypothesis that either (a) BD PROCHOT is just a bit too sensitive, or (b) there is some physical defect within the device that is causing targeted overheating (even though the overall device is only mildly warm to the touch).
I think this thread has coalesced around a specific issue when charging rather than sleep, and only in certain charge ranges (starting somewhere in the 70-80% range through 80-90% or so, whenever the charging rate lowers towards the end of charging, clocks get stuck at 400MHz, though clockspeeds never fully recover while charging through the end of the charge cycle). Several threads were merged into one so it’s a bit of a mess to read through, honestly if someone is experiencing a different issue probably should start a new thread for visibility.
@Bobby_Reynolds IIRC clocks bumping down to 200MHz might be related more EMI stickers on the USB ports or another issue entirely, have you read up on that?
RE: not everyone being affected, it’s possible sensor tolerance is in the expected range for the vast majority of users, but the range is too narrow so some users are getting false readings.
Update from my end… Once again my laptop had been sitting off, cold for close to a week. It didn’t respond to power button presses until I plugged in the AC adapter. Battery read at 76%. The RTC had been frozen across the time it was powered off (Windows thinks it is the afternoon of 10/23). CPU was stuck at 0.39GHz again.
Installed the 3.06 BIOS update. By the time it completed, battery was around 85%, and the CPU is no longer pinned at 0.39GHz. So I guess that’s another data point for the ~80% threshold being a factor.
Took a video of the side LED while waiting for it to boot after the BIOS update. White, 12 green blinks, then orange, blue, green, green, and back to orange (steady, charging).
Tomorrow I’ll check/reseat the CMOS battery and try adjusting the EMI stickers (hopefully without ripping any of them).
I just got my Batch 4 framework laptop and I am having this same issue. I was using the laptop while charging, once the battery gets to around 80% the CPU drops to 0.39 GHz. I am charging in the top right port relative to looking at the laptop as it is in use.
I emailed support today about it because I have heard of folks going through RMA processes. It’s not a huge deal for me, I usually just unplug my machine when it gets up around 80% and the CPU returns to normal. But still, I would like to see a resolution. It sounds like it’s only somewhat reproducible in Framework’s hands, which makes fixes tricky.
Oh rats…I wonder, it seems that some people aren’t seeing this issue, but others are. That’s at least why I thought an RMA might help (at least to give them a machine - mine - that I know is having this problem reliably) but your evidence is saying it might not help.
I guess we should just be patient, I know Framework is working on it!