I am affected by this from day one (Librem 13v3, a bit over a year old now). I am running PureOS, keeping it updated, and updating the firmware regularly. Nothing seems to make a difference.
That being said, it now happens much less frequently than during the first weeks.
I still don’t use the laptop regularly, in part because of the fan issue. I did use it constantly during a conference trip for a week, and the fan acted up exactly once.
Good luck,
Stefan
Nope and nope. 
It affects me as well. I estimate 1 of 5 wake from sleeps hits the fan bug for me. But I can “fix” it nearly every time by putting it back to sleep and waking it back up again. No solutions yet. I just got an email this week from Support stating there is not fix (yet).
Thank you for the lol’s 
I have an Librem 13v4 with Ubuntu 18.04 installed. At least for me running systemctl suspend or sudo systemctl suspend will replicate the issue about half the time (cpu at 400mhz, and fans blowing despite low temps). Rerunning typically fixes the issue.
I rarely have experience the issue otherwise but I use the power button to suspend the device, so I am wondering if perhaps the closing the lid is executing a different command than pressing power button.
Maybe this issue happens because MSR registers reset after resuming from sleep? I limited my CPU temperature to 65 C using thermal throttling feature, and after resuming from sleep target temperature alvays reset to original value (95 C).
Also, some registers retain the value after resuming from sleep. For example, my custom power limit don’t reset after sleep.
I think these “strange registers” may well be a good lead. Wasn’t there a recent Windows 10 update that caused similar issues on some laptops??
I’ve seen this behavior on my Librem 15 (that the fan goes full blast and performance slows).
For me it seems to correlate with switching between wired and WiFi. I’ll close the cover, unplug the USB Ethernet and the power (not necessarily in that order), then when I open the cover at a cafe, I get the symptoms. It happens less often when going from WiFi to wired.
Specifically, this (almost?) never happens in the course of opening and closing my Librem while it’s connected to power and wired 'net and in airplane mode—which is the usual way that I use it, like a desktop machine.
Edit: Okay, the fan bug triggered for me just a bit ago. But at least the change away from Wayland+Gnome made the bug apparently much much more rare. i can deal with once every few weeks.
It has been a few weeks now where I have not seen this bug recur for me.
The only thing I’ve correlated to it going away was that I switched to Xorg+dwm as my desktop instead of the standard Wayland+Gnome.
It doesn’t quite make sense to me that something in Wayland+Gnome could be causing a cpu throttling bug on wake, but that seems to be my experience at least.
intel says that if you want to neuder the ME and other blobs then you are “condemned” to live with a “fan-full-blast” to keep reminding you of the choice you made
Maybe my irony/sarcasm detector is off, but any supporting evidence would be appreciated.
I doubt that it’s the neutering of the ME engine that’s causing the problems (which are encountered very rarely these days). Having effectively “unique firmware”, however, does not help debugging / resolving this.
I would wish that some technical person from Purism would tell us what logs etc to provide once the issue hits (a rare event is difficult to debug!); e.g, the contribution from ‘scaled’(https://forums.puri.sm/u/scaled) above sounds promising and may have hit the underlying issue.
Intel: “ME turned off? We’re huge fans! Full blast fans, if you will”
I use a USB ethernet adapter at home, which I always disconnect when putting the laptop to sleep.
When plugging it in within the first ~10 seconds after wakeup, the chances of getting the full blasting fans is very high. When waiting a bit longer, it mostly works normal.
But every now and then, the fan issue is also happening without USB devices being plugged in after wakeup.
FWIW, I stopped having this problem with more recent versions of the Linux Kernel on my Librem 15 rev3 which has Arch Linux installed. This used to be an issue with 4.x kernels and earlier 5.x kernels but seemed to just go away at some point. I believe a more recent kernel combined with the appropriate coreboot upgrades will resolve the issue as I haven’t had this happen in months and I sleep/wake my Librem 15 multiple times a day, seven days a week. Sadly based on what I’ve seen PureOS is stuck on a 4.19 kernel but I assume that’s because they are tracking LTS kernels and that is still the most recent LTS kernel. The good news here is that the LTS kernel is definitely due to be upgraded so you PureOS users will probably get some relief sooner rather than later.
This used to be an intermittent issue and now it happens every time I reopen the lid to resume from suspend. What’s interesting is it only appears to be an issue when I resume by opening the lid. Specifically, if I open the lid and it goes into full fan slow CPU mode, I can clear it by selecting suspend from the mint GUI and then resuming by hitting any key. Also note that if I suspend the machine from the GUI, i.e. not losing the lid I haven’t noticed the problem.
HW: Librem 15, v3
FW: coreboot-l15v3.rom prebuilt binary, 2019/10/20
OS: Linux Mint 18.3 Sylvia, 4.13.0-26-generic
For what its worth I have this same issue on my work Thinkpad (same generation processor/chipset) that is currently running Debian. What happens is a thermal reading gets stuck on a certain number that never changes until you sleep again. Usually sleeping once again and then waking it up fixes it. It seems to be fixed on newer kernels than what Debian is using currently so should be a fix one of these days.
Thank for this info.
On my side, I run Debian stable. I compiled a newer version of the kernel (5.3.7) with Debian default compilation kernel config. I still had the full blast 2 days after, so either it is not related to the kernel version or it is linked to compilation configuration.
OK, so it just happened this way. Curiously, though the responsiveness of the system seems impacted, the CPU usage in top or System Monitor is 15-20% user and a few % system, with 70-80% idle.
Just happened for the first time for me today. Librem 13 (Feb '19 ).
power optimisation service is working, but has a “command failed: Operation not support (-95)” error in the systemctl status report, so that doesn’t look good.
any advice appreciated
So, it comes and goes. FWIW, while I can’t prevent it from happening, when it does occur I can correct it by executing systemctl restart suspend.target as root.
The problem went away after upgrading to coreboot firmware v4.11-Purism-1 (from v4.9).