I am also seeing random freezes, with a Librem 13 v2, running a freshly installed Ubuntu 17.10.
Kernel is 4.13.0-32.
The freezes seem random, regardless of load or activity. Alt-sysreq invocations don’t seem to work.
1 Like
A bit of a necro post but I’m figuring others might be watching this post – it looks like the upgrade to coreboot 4.7 Purism 4 helps with this.
I have removed intel_pstate=disable for almost 5 hours, running the same kind of workload that used to crash fairly fast (~10minutes) so I’m fairly confident it’s now fixed.
It’s been a while since I last tried to remove that intel pstate setting so it could also be a kernel upgrade (running 4.16.0, bleeding edge!), but some of the fixes that got in new coreboot hit fairly close to home (turbo etc) so if anyone still has the problem I’d suggest upgrading your coreboot 
I’m still seeing hangs with 4.7-Purism-4, although with a lesser frequency. I’m on stock Ubuntu 17.10.
Interesting, it’s been over half a week now and I’m using the librem heavily without any problem on this side now.
Out of curiosity, what’s your kernel version? Would be curious if it happens again if you upgrade/I downgrade
On the fun side, I would have expected intel_pstate to improve battery life, but it doesn’t seem to change much there. I guess it’s not exactly what I thought it was…
(oooh, new coreboot version brings in /sys/class/power_supply/BAT/current_now; that had been bugging me forever! awesome)
Actually, it’s been stable overall. I have a feeling there’s a separate issue, where if you close the lid and then open it right back, the interrupted attempt to sleep triggers a hang. I will experiment with this at some point, but the original issue may have been fixed.
I’m currently on 4.13.0-38-generic
I’m having the same issue. I’m running a librem 15v3 with reflashed coreboot and Qubes OS 4.0.
The freezes occur sometimes during boot-up when Grub asks me for a passphrase (and right then the system freezes, so I can’t type any keys) and sometimes when I’m running the OS and doing my normal work the system just suddenly freezes.
I would like to give you more info, but currently my system is hung up in the issue described at Librem 15 won’t turn on.
I’m using coreboot version 4.7-Purism-4 as well. This suggests that it might not be a debian (or PureOS) specific issue.
I also still get this issue also after specifying intel_pstate=disable to the kernel args via the grub menu.
Adding the kernel arg i915.enable_rc6=0, removed the issues with grub, however now my system starts freezing during normal use even more (it appears) and less randomly so (starting a browser usually freezes the system).
I’m still seeing intermittent freezes on 13v2 with 4.7-Purism-4.
1 Like
Actually, the kernel arg fixes the issue with grub only most of the time (90% or more). It tried various other combination of kernel args (including intel_pstate=disable), it doesn’t help either.
grub loads before (and independently of) the kernel, so kernel args shouldn’t have any impact on it… Unless it’s something about the state in which the GPU was when linux turned it off the previous time maybe, but that’s getting complicated…
I actually still have some glitches as well from time to time that make me reboot to clear it up, but I’m talking like once every few weeks of intense usage so I’ll probably just live with it…
Eh, it looks like I shouldn’t have written that, I’ve gotten 4 hard crashes in these past few days, with and without intel_pstate=disable -_-
(always while a video or game was running so involving GPU activity, and mostly when I was also compiling something in the background but not always; pretty much the same as the original posts for a while back; none of the time did the network hold up to ssh in and I couldn’t get kdump to work either possibly because of encryption, I’ll try to point it to a plain device next)
I guess a kernel upgrade made it worse somehow, but honestly at this point I’m putting it on a bad series where the hardware tolerance would have gotten pushed too close to the limits and was going to let it slide, but if it’s happening more often again I guess I’ll have to spend some more time on this…
@ everyone - my 2 cents …
it’s not a PureOS issue. it’s not a debian issue. it’s not even Fedora or CentOS related it is about the free drivers (linux kernel or video drivers not firmware)
i’ve been running all these distributions on the same desktop hardware for many months and the same freezing happens at random intervals requires imediate reboot. this happened with both X-org and Wayland on each distribution no proprietary software drivers installed. just the one that shipped with each distribution. all 2018.
with windows and proprietary drivers this never happened. it is not a question of firmware here. just drivers.
the hardware in use was
amd ryzen 1800x on asrock itx x370 with quadro k1200 eGPU samsung 960 evo
then the same happened on
amd ryzen 2200g on asrock itx x370 with vega 8 iGPU samsung 960 evo
it is not a matter of PureOS only it is everywhere there is Linux and open source drivers. they are not optimized.
windows is optimised so it doesn’t freeze so it doesn’t need to restart so it can spy more. yay !
I have an interesting updated for all concerned on this post… I have had no screen freezing issues for several months now!!!
What has changed? My laptop crashed from running out of battery power, an issue that I still haven’t managed to fix. However, an incomplete update/upgrade meant the machine was not rebooting. I was not able to fix the broken installs, my linux knowledge is too shallow and I just don’t have the time to dive into this, so I decided to simply re-install. However, a fresh installation on an encrypted partition does not work and I therefore had to do a default install on an non-encrypted partition, along with a swap partition (which my previous factory-install did not have).
Since then I haven’t had a single issue with screen freeze. So could it be a due to a lack of swap partition or encrypted partition or maybe both that is at the root of this issue?
1 Like
that is a solid no. i’ve tested it like you describe on much more hardware and software combination and it is not the issue.
in the future i will try with a debian stable with xorg non proprietary drivers on my hardware to see if the issue remains the same and i will update here at such point.
Yeah, I don’t think it’s directly any of that. The more time passes and the more convinced I am it has something to do with power circuits failing somewhere, at least in my case.
- carefully keeping a power setting for the cpu is usually safe for me (e.g. powersave or performance)
- yesterday I’ve had a couple of crashes with powersave while playing videos as usual, which hadn’t been happening so much lately, and I just noticed the power chord was unplugged so the difference from usual is that I was on battery only. I’m not sure if that is because the power supply was different or if the energy consumption plan changed due to being on battery.
- crash never happens when computer is idle and simple continuous CPU or memory stress tests do not bring it down, but usually loads that make the power consumption vary a lot will crash it: video playback that uses half of a core if normal throttling applies keep varying the frequency and thus power consumption; and video decoding uses sse/vector instructions which are more energy intensive than normal workload.
I also got crashes compiling big projects, that is a lot of cpu ups and downs + burst writes to disk.
I don’t see what swap would have to do with that, but disk encryption makes your CPU use AES instructions which also consume slightly more power when you read/write to disk, so that could make a slight difference there as well.
Speaking of disks I did try removing the sata drive but I don’t think I ever tried running without the nvme disk; I guess it’s worth a try.
Anyway, I’ve pretty much given up on this one. My laptop usage is simple enough that I won’t crash often if I’m a bit careful so I’ll bear with it for the life span of the laptop; after half a year of seriously using the librem15 I’m much more annoyed at the touchpad quirks/keyboard layout than this random crash issue 
I experience this hard lock issue on my Librem 13 v3 which only seems to happen after resuming my computer from suspending to RAM; it happens in a few minutes to a few hours after resuming . I haven’t been able to log any useful messages after enabling Storage=persistent in /etc/systemd/journald.conf.
But I saw a similar issue on my older ThinkPenguin Korora laptop using an Intel Haswell chipset and my kernel logs on that machine pointed to a kernel panic with the Intel GPU microcode. I worked around that by disabling the iommu per a suggestion on the Arch Linux forums which worked nicely. I was running Gentoo on that machine, so I had disabled CONFIG_IOMMU in the kernel itself.
Presumably one can do the same thing by by appending iommu=off to /etc/default/grub and running sudo update-grub but that seems to prevent affects the Atheros wifi from initializing (the last 3 lines here):
$ sudo journalctl -b0 -k -p3
-- Logs begin at Wed 2019-02-06 14:28:44 EST, end at Mon 2019-02-11 12:53:34 EST. --
Feb 11 12:46:42 xm2 kernel: i915 0000:00:02.0: firmware: failed to load i915/skl_dmc_ver1_27.bin (-2)
Feb 11 12:46:42 xm2 kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
Feb 11 12:46:42 xm2 kernel: usb 1-3: firmware: failed to load ar3k/AthrBT_0x11020100.dfu (-2)
Feb 11 12:46:42 xm2 kernel: Bluetooth: Loading patch file failed
Feb 11 12:46:42 xm2 kernel: ath9k 0000:01:00.0: dma_direct_map_page: overflow 0x000000046303d040+1974 of device mask ffffffff
Feb 11 12:46:42 xm2 kernel: ath: phy0: dma_mapping_error() on RX init
Feb 11 12:46:42 xm2 kernel: ath9k 0000:01:00.0: Failed to initialize device
So instead of iommu=off I pass intel_iommu=off to grub:
$ sudo journalctl -b0 -k -p3
-- Logs begin at Wed 2019-02-06 14:28:44 EST, end at Mon 2019-02-11 13:09:54 EST. --
Feb 11 13:09:01 xm2 kernel: i915 0000:00:02.0: firmware: failed to load i915/skl_dmc_ver1_27.bin (-2)
Feb 11 13:09:01 xm2 kernel: firmware_class: See https://wiki.debian.org/Firmware for information about missing firmware
Feb 11 13:09:01 xm2 kernel: usb 1-3: firmware: failed to load ar3k/AthrBT_0x11020100.dfu (-2)
Feb 11 13:09:01 xm2 kernel: Bluetooth: Loading patch file failed
I’ll report back in a few days with whether the freezing goes away.
All is well now after adding intel_iommu=off to GRUB_CMDLINE_LINUX_DEFAULT and running sudo update-grub. I haven’t had any more freezes after resuming from suspend. 
Would like to revive this post as I had this issue with a new L15 V4 with kernel version 4.19.0-5-amd64 and X11 (not Wayland)!
I have experienced regular (every 6 hours or so) freezes when running videos on Firefox. And as @vrata said the last second of audio loops when that is the case. I think I have had the freeze occur without playing videos as well, but I’m not sure if it has to do with what @omsai is talking about.
Are there any updates on this? Did any of @Asmadeus or @vrata try @omsai’s fix or figure out another?
I replaced my librem, mostly because of this bug that still happened once in a while - it’s been much less frequent after playing with cpufreq scaling governors and forbidding cpu frequency swings for me so if you haven’t done that yet give it a try.
That said if you didn’t buy a librem around the same time this post was created I don’t think it’ll be the same issue, it really looks like there was a bad production run somewhere (CPU chip or motherboard or power circuits or…) and we were a few unlucky folks. If your librem is new-ish you might want to get in touch with the support.
I’ve not had any further problems with freezing.