Hi kelnos,
This thread is getting pretty long and goes back a bit, and there are a few things that deviate outside of a vanilla install. If you do not have an active ticket, please create one and link to your posts.
My 12th gen does not exhibit this behavior, but I also keep to a pretty vanilla (guides specific) installation.
Thanks
Support had me test on the “blessed” Ubuntu LiveCD linked from Framework’s website, and I was able to easily reproduce the issue, both on my original board, and the replacement board that was shipped to me.
(Regardless, if the Framework laptop cannot run a vanilla Debian stable install – I’m now running stable since testing was promoted to stable in June – that’s… pretty atrociously messed up.)
Not sure if my support ticket is still “active”; they had me perform a bunch of troubleshooting steps, and I got shuffled back and forth between several support people who kept asking me to do the same things I’d already done and had provided results for. At this point I’m not sure what else to do on that support ticket, as they’ve given me no further instructions. It’s been incredibly frustrating, to be honest.
Okay, if this is happening on a replacement board and we cannot replicate it. That does put us in a rock and a hard place as something else we cannot duplicate is happening.
We do not test again distros outside of what we have listed. We do however, have multiple pinned community Debian guides.
I would reply to to your last email from the ticket and see what the suggested next steps would be. I imagine if you were sent another board and are still seeing the issue, it would need to be elevated to engineering as we cannot replicate the environment affecting two separate boards (yours and the replacement).
I’m out of town for the next couple weeks, but will do so when I get back home.
Would it not make sense for me to return one of the two mainboards I have that exhibits the problem, and then your support or engineering team can attempt to reproduce it on that board?
Replying to the ticket when you return sounds fine.
Hi everyone,
I encounter the same problem regularly as well. Since I use an eGPU I tend to play a bit heavier games that do not take this throttling lightly: They stutter, freeze and/or crash and sometimes even take down the whole system. I reported this initially in another thread because I didn’t monitor the CPU frequencies back then (htop doesn’t show them): However using s-tui I can monitor that before every crash/freeze the frequency of all cores bumps down to 400 MHz and stays there even after the crash. It can take some time (even through reboots) until the CPU recovers, sometimes it takes half a minute, sometimes more than 10 minutes.
Reproducing this issue is a bit cumbersome, since to me it only occurs after a certain amount of time in the game (0,5-2 hours depending on the game and whether I use the iGPU or not). What I find particularly strange is that in the moment of throttling the CPU isn’t even extremely hot: With my eGPU it sits around 90° up to 95° tops even right before the crash. If I do other CPU-heavy work (which don’t last as long) like compiling code, the CPU can get up to 100° hot without any core throttling down to 400MHz. The only difference I can think of is, that after a 2 hours gaming session the heat has spread over the whole laptop (to other components and the outside of the housing which is quite hot at this point). Maybe this somehow triggers this throttling instead of the temperature inside the CPU? I will definitely do some more testing on this, maybe even on Windows (if this is indeed a Firmware issue, then Windows should be affected as well)
System:
CPU: i7-1260p
RAM: Crucial 3200MHz 32GB
SSD: WD-Black SN850 2TB
OS: Arch Linux (kernel 6.4.11-zen2-1-zen)
Since we do not test against eGPUs, we cannot speak to this.However, if you see throttling, please do test on Windows well for the eGPU. Linux eGPU handling is a mixed bag, so it can be helpful to have a comparison.
Hi @Matt_Hartley, I again put this off out of frustration, but finally emailed again on the support ticket 3 weeks ago, and again 2 weeks ago, after receiving no response. Any idea why Framework Support seems to be ghosting me?
Hi @kelnos,
Your ticket is in with the engineering escalations, I have added a note indicating that you are on the 3.08 BIOS. What games are you trying to play and with which distro/kernel?
Thank you for the update, @Matt_Hartley.
My usual game reproducers are Left 4 Dead 2 and Stellaris. Sometimes I can go an hour or so with L4D2 without seeing it occur, but with Stellaris it usually repros within 20 minutes or so. I can repro faster if the vents on the bottom of the laptop are partially blocked by my lap, though it still happens soon enough if it’s on a hard surface like a table.
These are not particularly “strenuous” games; they play just fine on my older 2018 Dell XPS 13.
I’m currently running Debian testing (trixie), kernel 6.6.13. This also occurs on Debian stable (bookworm), any kernel in the 6.2, 6.3, 6.4, 6.5, and 6.6 series, and likely older.
During previous support interactions, I’ve also reproduced this using the Ubuntu 22.04 LTS image linked from Framework’s Linux page, by creating a tmpfs volume and compiling the Linux kernel (with make -j20) over and over.
The OS doesn’t seem to matter once it’s in this state: I can reboot the laptop and enter BIOS settings or the GRUB prompt, and if it’s still throttled I can see sluggish cursor movement and screen redraw.
I’ve disabled turbo boost (both in the BIOS and in sysfs on Linux, and in tlp’s config). I’ve also experimented with throttled, limiting TDP before doing some “softer” throttling, but that hasn’t helped. I’ve also run through support’s suggestions to try removing and shuffling the RAM around, as well as removing the NVMe drive (running the OS off a USB stick) and Wifi card… plus a lot of other stuff they’d asked me to do.
Appreciate the update. We’ll need to see what the escalation team is able to sort from this. In instances where reproduction is tricky, this becomes harder.
On the 16th, we emailed you with thoughts from our engineering team. I’ve added in your latest feedback about the games and tmpfs volume into the ticket as well.
Yep, got the email, unfortunately while I was out of the country. Just got back yesterday and will try the new troubleshooting idea.
You were asking in another thread what thermal paste I used to solve this issue for me. It’s this noctua thermal paste from amazon. I took my time and was very deliberate about removing the old thermal paste. I even used a little isopropyl alcohol on a q-tip to completely remove it. Then I was pretty generous with applying the new paste.
Other than that, all I did was to use compressed air to blow out the fans. Hope this helps.
I haven’t had the opportunity to try new thermal paste, but I’ve been playing with a possible workaround, at least for gaming: restricting the GPU’s max clock frequency. This seems to be more or less working, though at the expense of worse performance in games, and the need to reduce quality settings in the games themselves.
On Linux I set the values in both /sys/class/drm/card0/gt_max_freq_mhz and /sys/class/drm/card0/gt_boost_freq_mhz to something lower. Looks like they default to 1450. I started by dropping them down to 650, and have been inching them back up, 100MHz at a time, with so far good results up to 950MHz.
My admittedly qualitative test is to stretch out on my couch, put a blanket over myself, the laptop on top of my lap with the blanket under it, and start playing Civilization VI. At the default of 1450MHz, the throttling kicks in after 10 minutes or so. At 950MHz and below I was able to play for several hours with no issues.
I’m still testing (next stop: 1050MHz), so hopefully I still have room to run it faster here. This is a decent workaround: I’m happier to be able to play games at all, vs. having to save and quit every so often when the laptop decided to misbehave (especially a problem with online multiplayer games). But it’s still pretty lame that I have to live with worse perf and lower graphics quality for this to be usable.
And this isn’t a complete workaround. As I’ve mentioned, I can trigger this just by running Linux kernel compiles at full-tilt, even when the GPU is more or less idle.
Update: 1050Mhz was too high. I did manage to play for a about 3 hours before it throttled and got stuck. Will try bumping down to 1000MHz and see if that’s stable. Otherwise it might be 950.
Update2: 1000MHz was no good either; this time it throttled after an hour and a half or so. Back to 950.
Running on an i7-1260p, 64GB RAM, 1TB NVMe, 3.08 BIOS, under Fedora 40.
I changed the thermal paste to a Noctua NT-H2 and cleaned up the fan, the improvement is marginal.
I have disabled Hyper-Threading, yet when is under load (compiling for a couple of minutes) it reaches above 95°C-100°C it starts throttling to 400 MHz and it takes almost half an hour to return to its normal state (when in idle).
The only solution I have found is to limit the CPU frequency using cpupower to 1.8GHz:
sudo cpupower --cpu all frequency-set --max 1.8GHz this way the temp is around 80°C under load but at least it does not throttle.
This sucks big time since I select an i7 to have a powerful processor, yet I have to limit it to behave like an i3 (or less).
I don’t know why the cooling system from 13in laptops (in general) is awfully bad, I know about the space constraints, but the way the fan is positioned is just a poor design from every single vendor, airflow is pretty bad and the heatsink too small for a power chip.
Note for my future self: Buy the lower-end CPU available, it will work the same as a high-end CPU.
Hyperthreading doesn’t reduce the max thermal output much.
It almost sounds like it runs into one of the harder thermal limits (but not the had hard one otherwise you’d just have a crash) and panics to 400mhz, have you tried turning down the soft thermal limit and see if that helps?
The cooling in the framework 13 is actually pretty nice for the size, I think there is something screwy going on with yours.
You are using intel_pstate and not some legacy frequency scaling thing right?
My experience tells me otherwise, you might be surprised but it helps.
The cooling is pretty nice? not sure if you are using the i5 version, have a special limited edition, or living in Norway, but every single laptop of this size has this cooling design flaw, I’m not blaming Framework, every vendor has this issue, for me, the cooling of the framework is pretty standard, and yes, I’m using intel_pstate.
It can reduce it in certain workloads but you can definitely easily still exceed the power limit without it.
I’m using the r7 version, stock it can cool a bit under 30w, with ptm or liquid metal around 45, that’s quite a lot for that size bracket.
The throttling behavior you are seeing does not look right though, proper throttling should ride the power/temp limit and not crash to 0 when it reaches the max temp. The newest intel notebook I have access to is 11th gen and it does pretty much exactly that, so do the older ones. Can you reproduce this behaviour on windows or an ubuntu live system?
Edit:
In active mode?
Yes, under certain workloads it helps, and yet as mentioned, I still hit the thermal throttling even without HT.
I don’t have an “r7” version, I have the i7-1260p, and not use liquid metal either, then it might be my fault for not using liquid metal 
the whole thread is about the 12th gen, so it might be an issue specific to the 12th gen, in any case, that doesn’t invalidate that practically every 13-inch laptop (any vendor) has a poor cooling system.
$ cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_driver
intel_pstate
intel_pstate
intel_pstate
intel_pstate
intel_pstate
intel_pstate
intel_pstate
intel_pstate
intel_pstate
intel_pstate
intel_pstate
intel_pstate
$ cat /sys/devices/system/cpu/intel_pstate/status
active
Don’t worry, I can live with this issue, so this is my last reply. 
Nah, even 30W should be more than enough for quite a bit of performance. The liquid metal just gets me more of it.
This is most likely not a cooling issue but a frequency scaling one. Even desktop chips are power limited these days. Running at the temp/powerlimit is normal these days, partially even on desktop, getting stuck at min clocks is not.
The stuck at 400mhz thing is not supposed to happen, that’s some kind of bug.
That works too I suppose but it’s kind of a waste.