This absolutely feels like a damaged slot. Please open a ticket if you have not already.
I’ve started experiencing the same thing over the past few months but on my 13th gen intel. I’ve tried updating to the latest beta BIOS 3.06 and still have the same problem. I’ve raised a support ticket. Fingers crossed it can be fixed.
After debugging with support it seems to be solved but I don’t know which step solved it, it was one of combination of:
- Disconnecting the battery, running in standalone, then reconnecting it
- Dismantling the fan/heatsink and cleaning it (it wasn’t very dusty)
- Resetting the mainboard (see instructions below)
It’s been happily running as expected for nearly a week without issue.
Mainboard reset:
- Plug in system to AC
- Remove input cover
- Press the chassis open switch in the center of the mainboard 10 times, you must press it slows, so press for 2 seconds. Release, wait for the red blink on the Mainboard LEDs, and repeat.
See the photo below for reference:
- Press the power button to boot the system.
- BIOS settings will be reset to defaults.
The issue started again a few weeks ago, framework support have now told me to go buy a new mainboard because it’s out of warranty which is a complete joke I’ve been having issues with this thing in one form or another since I got it. So much for framework’s mission to prevent e-waste now this thing will end up on the scrap heap and be replaced with a thinkpad.
I also have had this problem come back recently. It is weird because it oscillates between long periods of 400mhz and then sometimes wakes up and becomes snappy again. It is incredibly annoying.
Hi, for what it is worth I had something similar on my 13th gen - have a check of the fans and cooling tunnels, and possibly the thermal paste on the CPU.
Do you have a specific workload that triggers the 400mhz behavior?
No, it was nothing special or distinctive in the workload. My devices all run Ubuntu 24.04 so are reasonably lean once they’ve started up but it really didn’t take a lot for it to throttle and the fans going full pelt.
The issue in my case was simply that the fans and cooling vent were blocked causing it to throttle back with a very very low threshold.
I had the issue in both my Framework 13 and the Mobo I run as my desktop in a Coolermaster case with the Coolermaster case being the worst at clogging up. Both these are running Intel 13th gen (the laptop a 1340p, the desktop a 1370p) with 64GB RAM and either a 500GB or 2TB NVMe drive so most of the time neither is exactly stressed out with memory management.
For me it was caused due to thermal.
I was experiencing this issue occasionally in the past but recently it became every day struggle to the point that it made every day work a challenge.
I started checking temps and noticed that it ran quite hot most of the time ~80c but never over 90c.
I cleaned the fan and applied new thermal paste I haven’t had the issue since.
Bumping this, as I also have the issue on Core Ultra 125H.
It was capping out at 77˚C. After taking out the battery for a while and plugging it back in, it could suddenly go to 90. But it caps out there.
I’m really hoping to get it to reach 95. These chips are supposed to work up to 110. It’s very disappointing that the BIOS settings prevent the chip from getting the advertised performance.
As a reference, the CPU score on Intel Core Ultra 5 125H Benchmark is supposed to be over 20K. I was getting 9K before the BIOS reset and am only getting 16K now.
If anyone would like to share their results, It’d be welcome.
Hi everybody,
It seems I am facing the same issue as several others in the community. I have an i7-1360P and the latest BIOS installed (3.16). I tried many times since I got my Framework in 2023 to replace Windows 11 with Fedora. I also have an eGPU and I got it working. However, the issue is my CPU. It never goes full throttle.
The past few days I tried Fedora 44 and I tried solving that issue that I had before. I tried all kinds of CPU stress testing but my CPU spikes at 100 degrees Celsius for less than a second and then throttles back to 70 degrees stable and all my cores are locked at 1.5 GHz (!!!). At this point, this is unacceptable. I had the same issue since Fedora 39.
At this point I have no idea what I am supposed to do. I really want to get rid of Windows 11, but in Windows I don’t have these issues. I have also installed Thermal Grizzly PhaseSheet PTM which helped my thermals a lot, so it’s not the paste. I also tried resetting all my BIOS settings to the default ones, but nothing changed.
I have attached a screenshot showing the exact moment the CPU flatlines at 1.5GHz despite being under full load.
Can you try the following and say what the setting is both before the spike and after the spike
sudo ectool gpioget | grep h_prochot
Out put is:
1 h_prochot_l 0xA0006 ← No PROCHOT from the EC GPIO.
0 h_prochot_l 0xA0006 <-PROCHOT from the EC GPIO.
The above works for AMD laptops.
You might need to do sudo ectool gpioget and then look for something that looks similar to prochot and then grep for that.
Thanks for the tip! On my Intel 13th Gen, the command you suggested didn’t work, but I found the equivalent GPIO pin using: sudo framework_tool --get-gpio | grep -i prochot
Currently, it returns EC_PROCHOT_L 1, but that’s because I’ve successfully implemented a workaround.
What I found: Before the fix, my i7-1360P would hit a brief load, spike in temp, and then “crash” into a persistent 1.5GHz / 15W state. It wouldn’t recover even after the CPU cooled down to 70°C.
I checked the MSR registers (sudo rdmsr 0x1FC) and found it was stuck at e4005b. That b bit confirmed that the Embedded Controller was latching BD PROCHOT and refusing to let go. Additionally, turbostat showed that while the OS requested higher power, the firmware-level MMIO limit was hard-locked at 15W.
How I fixed it: I installed the throttled daemon (erpalma) to manually override the EC’s interference. I had to set the update rate to 1 second to “fight” the EC, as it keeps trying to re-apply the throttle.
My /etc/throttled.conf settings that finally worked:
[AC]
Update_Rate_s: 1
PL1_Tdp_W: 28
PL2_Tdp_W: 64
Trip_Temp_C: 99
Disable_BDPROCHOT: True
Results: The difference is night and day. Once throttled cleared that BD PROCHOT bit, the CPU immediately scaled up. I just finished a Geekbench 6 run with a Multi-Core score of 10,044 and Single-Core of 2,681.
Do you have any idea why this is happening out of the box? It seems pretty weird
Multiple things might be causing the BD PROCHOT.
If the EC_PROCHOT_L 1, then it is not the EC causing it.
It is difficult to tell what else might be causing the BD PROCHOT as we don’t have a full schematic, so don’t know what else is linked to it.
Another guess might be the Battery charging chip. It has a PROCHOT output, but I don’t know if it is connected to BD PROCHOT or not.
Normally various temp sensors from the chipsets trigger PROCHOT, so it could a a VRM overheating, or some other chip overheating or the battery overheating. Thus suppressing BD PROCHOT might eventually damage the CPU or burn out chips on the mainboard.
In general, I would say it is unsafe to disable BD PROCHOT.
You can manually use this to force the EC PROCHOT, and see if it triggers the same slowing symptoms and see if it sets the rdmsr 0x1FC
sudo ectool gpioset EC_PROCHOT_L 0
Unset it with:
sudo ectool gpioset EC_PROCHOT_L 1
Note: I thought this thread was about a 12th Gen Intel FW13. From the title, but you mentioned 13th Gen.
I performed a further diagnostic test by physically removing the internal battery and disabling the throttled daemon. Under a stress test on AC power alone, the CPU remained hard-locked, reaching a maximum of only 1.7GHz.
Here are the specific results from the terminal during that state:
-
~$ sudo framework_tool --get-gpio | grep -i prochot→ EC_PROCHOT_L 1 -
~$ sudo rdmsr 0x1FC→ e4005b
Analysis of these results: The fact that EC_PROCHOT_L is 1 (High) proves that the Embedded Controller is not asserting the throttle signal. However, the b bit in MSR 0x1FC confirms the CPU is still receiving a hardware-level BD PROCHOT command.
Since the EC is clear, this signal must be coming from another component on the shared PROCHOT line—likely the charging circuitry or voltage regulators erroneously signaling a power-delivery emergency.
As I’ve mentioned, this behavior is completely absent in Windows 11, where the system functions perfectly under the same loads. This confirms the hardware and cooling (Thermal Grizzly PTM) are 100% functional. Could this be a bug in how the 13th Gen firmware handles power/thermal state negotiation specifically on Linux?
A small update: I run this on my terminal and got the following results:
gianniszes@fedora:~$ for zone in /sys/class/thermal/thermal_zone*; do
echo -n "$(cat $zone/type): "
echo “scale=2; $(cat $zone/temp) / 1000” | bc | sed ‘s/$/°C/’
done
acpitz: 58.80°C
acpitz: 47.80°C
TCPU: 57.05°C
TCPU_PCI: 58.00°C
x86_pkg_temp: 58.00°C
iwlwifi_1: 33.00°C
acpitz: 51.80°C
acpitz: 48.80°C
acpitz: 0°C
INT3400 Thermal: 20.00°C
SEN2: 48.85°C
SEN3: 47.85°C
SEN4: 180.85°C
SEN5: 51.85°C
Maybe these 2 sensors (acpitz: 0°C and SEN4: 180.85°C) are the reason behind this behavior?
Please post the output of “sensors”.
It should describe which device the problem 0 C and 180 C are from.
I would say, that both those are worth investigating with regards to prochot.
Someone mentioned up above, but worth opening the laptop and check that the fans etc, are free of dust.
Also, it is not only external devices that can trigger prochot. The cpu can also trigger it for itself.
This is the output of sensors: When I posted the earlier results I had the battery removed and the keyboard was not making good contact with the chassis.
$ sensors
iwlwifi_1-virtual-0
Adapter: Virtual device
temp1: +34.0°C
cros_ec-isa-0000
Adapter: ISA adapter
fan1: 3973 RPM
F75303_Local: +48.9°C (high = -273.1°C, crit = +87.8°C)
(emerg = +97.8°C)
F75303_CPU: +56.9°C (high = -273.1°C, crit = +87.8°C)
(emerg = +97.8°C)
F75303_DDR: +52.9°C (high = -273.1°C, crit = +86.8°C)
(emerg = +96.8°C)
Battery: +34.9°C (high = -273.1°C, crit = +49.9°C)
(emerg = +59.9°C)
PECI: +67.8°C (high = +114.8°C, crit = +119.8°C)
(emerg = +126.8°C)
F75397_VCCGT: +52.9°C (high = -273.1°C, crit = +87.8°C)
(emerg = +97.8°C)
BAT1-acpi-0
Adapter: ACPI interface
in0: 17.59 V
curr1: 290.00 mA
coretemp-isa-0000
Adapter: ISA adapter
Package id 0: +68.0°C (high = +100.0°C, crit = +100.0°C)
Core 0: +64.0°C (high = +100.0°C, crit = +100.0°C)
Core 4: +57.0°C (high = +100.0°C, crit = +100.0°C)
Core 8: +67.0°C (high = +100.0°C, crit = +100.0°C)
Core 12: +61.0°C (high = +100.0°C, crit = +100.0°C)
Core 16: +67.0°C (high = +100.0°C, crit = +100.0°C)
Core 17: +67.0°C (high = +100.0°C, crit = +100.0°C)
Core 18: +67.0°C (high = +100.0°C, crit = +100.0°C)
Core 19: +68.0°C (high = +100.0°C, crit = +100.0°C)
Core 20: +65.0°C (high = +100.0°C, crit = +100.0°C)
Core 21: +65.0°C (high = +100.0°C, crit = +100.0°C)
Core 22: +65.0°C (high = +100.0°C, crit = +100.0°C)
Core 23: +64.0°C (high = +100.0°C, crit = +100.0°C)
nvme-pci-0100
Adapter: PCI adapter
Composite: +45.9°C (low = -273.1°C, high = +81.8°C)
(crit = +84.8°C)
Sensor 1: +45.9°C (low = -273.1°C, high = +65261.8°C)
Sensor 2: +50.9°C (low = -273.1°C, high = +65261.8°C)
acpitz-acpi-0
Adapter: ACPI interface
temp1: +67.8°C
temp2: +52.8°C
temp3: +56.8°C
temp4: +52.8°C
temp5: +34.8°C
However, I run this command: $ sudo framework_tool --console recent
7295.280692 HC 0x98]
disabled]
[7282.224444 HC 0x97]
[7282.225573 HC 0x98]
+++(++)[7282.309458 HC 0x51]
+++(++)[7282.470704 HC 0x97]
[7282.471820 HC 0x98]
+++(++)[7282.631146 HC 0xa0]
[7282.714636 HC 0x97]
[7282.715706 HC 0x98]
+++(++)[7282.957900 HC 0x97]
[7282.959736 HC 0x98]
+++(++)[7283.029425 Sustain mode disabled]
[7283.205720 HC 0x97]
[7283.206705 HC 0x98]
+++(++)[7283.447894 HC 0x97]
[7283.448976 HC 0x98]
+++(++)[7283.695318 HC 0x97]
[7283.696424 HC 0x98]
+++(++)[7284.032517 Sustain mode disabled]
[7284.639306 HC 0xa0]
[7284.844535 HC 0x04]
[7284.846254 HC 0x3e01]
[7284.847324 HC 0x02]
[7284.850576 HC 0x3e01]
[7284.851805 HC 0x9e]
+++(++)[7284.866452 HC 0x3e1e]
[7284.867267 HC 0x3e1e err 1]
[7285.034438 Sustain mode disabled]
[7286.036974 Sustain mode disabled]
[7286.228492 HC 0x3e03]
[7286.229092 Sustain mode disabled]
+[7286.231961 Sustain mode disabled]
[7286.649770 HC 0xa0]
[7287.039416 Sustain mode disabled]
[7288.041897 Sustain mode disabled]
[7288.251798 HC 0x3e03]
[7288.252365 Sustain mode disabled]
+[7288.255493 Sustain mode disabled]
[7288.387997 HC 0x51]
+++(++)[7288.657881 HC 0xa0]
[7289.044227 Sustain mode disabled]
[7290.046269 Sustain mode disabled]
[7290.126019 HC 0x04]
[7290.127747 HC 0x3e01]
[7290.128806 HC 0x02]
[7290.132197 HC 0x3e01]
[7290.133324 HC 0x9e]
+++(++)[7290.148686 HC 0x3e1e]
[7290.149256 HC 0x3e1e err 1]
[7290.309126 HC 0x3e03]
[7290.309772 Sustain mode disabled]
+[7290.312776 Sustain mode disabled]
[7290.666760 HC 0xa0]
[7291.048190 Sustain mode disabled]
[7292.051228 Sustain mode disabled]
[7292.343762 HC 0x3e03]
[7292.344343 Sustain mode disabled]
+[7292.347352 Sustain mode disabled]
[7292.495547 HC 0x51]
+++(++)[7292.673254 HC 0xa0]
[7293.054211 Sustain mode disabled]
[7294.056132 Sustain mode disabled]
[7294.378257 HC 0x3e03]
[7294.378818 Sustain mode disabled]
[7294.465617 HC 0x3e03]
[7294.466191 Sustain mode disabled]
[7294.686402 HC 0xa0]
[7295.058655 Sustain mode disabled]
[7295.279651 HC 0x97]
Could this be related to my issue?

