Yes
Now I re-installed PureOS for another issue I am having right now, please help if you can
though I will keep you updated if I again experience system freeze, I disabled intel pstate right after I finished installing OS. Hope that helps.
1 Like
For the freezing issues, it might help if you install “SKYLAKE GUC - 9.33” firmware from this page: https://01.org/linuxgraphics/downloads
This might help us debug the issue. Instructions are provided within the package.
1 Like
Does this hold true for the Librem 13v2 as well?
downloaded the tar archive and extracted it to a temp location, from a terminal I executed the following file in the extracted folder,
sudo ./install.sh
the binary file was installed and I was instructed to reboot.
However, I don’t see any changes in the firmware after reboot,
$ modinfo i915
filename: /lib/modules/4.13.0-1-amd64/kernel/drivers/gpu/drm/i915/i915.ko
license: GPL and additional rights
description: Intel Graphics
author: Intel Corporation
author: Tungsten Graphics, Inc.
firmware: i915/bxt_dmc_ver1_07.bin
firmware: i915/skl_dmc_ver1_26.bin
firmware: i915/kbl_dmc_ver1_01.bin
firmware: i915/kbl_guc_ver9_14.bin
firmware: i915/bxt_guc_ver8_7.bin
firmware: i915/skl_guc_ver6_1.bin
firmware: i915/kbl_huc_ver02_00_1810.bin
firmware: i915/bxt_huc_ver01_07_1398.bin
firmware: i915/skl_huc_ver01_07_1398.bin
my guc is still at v9.14 which is I had earlier reported in this thread.
Am I missing something?
[EDIT] this is what I get when I install the firmware, its warns of several missing files, but still reports of a successful installation,
$ sudo ./install.sh
Success: /lib/firmware/i915/skl_guc_ver9_33.bin installed!
Forcing initrd/initramfs update...
Trying to backup /boot/initrd.img-4.13.0-1-amd64
Created a bakcup of your current initramfs /boot/initrd.img-4.13.0-1-amd64.i915-fw.backup
Trying to update /boot/initrd.img-4.13.0-1-amd64
update-initramfs: Generating /boot/initrd.img-4.13.0-1-amd64
WARNING: Setting CRYPTSETUP in /etc/initramfs-tools/initramfs.conf is deprecated and will stop working in the future. Use /etc/cryptsetup-initramfs/conf-hook instead.
W: Possible missing firmware /lib/firmware/i915/bxt_dmc_ver1_07.bin for module i915
W: Possible missing firmware /lib/firmware/i915/skl_dmc_ver1_26.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1_01.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_14.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver8_7.bin for module i915
W: Possible missing firmware /lib/firmware/i915/skl_guc_ver6_1.bin for module i915
W: Possible missing firmware /lib/firmware/i915/kbl_huc_ver02_00_1810.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_huc_ver01_07_1398.bin for module i915
W: Possible missing firmware /lib/firmware/i915/skl_huc_ver01_07_1398.bin for module i915
Adding /lib/firmware/i915/skl_guc_ver9_33.bin
Success: Please reboot your machine!ok, I got another freeze today, but due to lack of another computer I couldn’t try @Caliga’s suggestions of ssh’ing into my frozen laptop… BUT I got another interesting symptom to report, I was listening to SoundCloud, a streaming music platform on my browser when the freeze happened, and the music didn’t completely stop playing but instead looped over the last second of play. This platform streams mp3 which is partly cached on the browser, therefore I am assuming that the decoding froze, but the audio didn’t.
So can this point to a cpu issue as @Asmadeus suggested in his post?
However, rereading @david.libremone’s post,
I have to admit that all my freezes happen while running Firefox. Odd because this time I was running FF Quantum which I believe is a total re-write of FF.
One of our devs also reported freezes when running Firefox.
Interesting, is this something Purism is looking into or will look into and fix ?
Just stumbled upon this LWN article, perhaps one of the tools could help come up with a reproducible crash case?
I found a way to recover from a Firefox freeze. The screen is frozen and so is my external mouse/trackpad/keyboard unresponsive. I found that by actually closing the lid (I have mine configured to put the computer in sleep mode) and re-opening it, the screen is still in its frozen capture, but I can now press the ‘Enter’ key and the screen finally goes blank, I press the ‘Enter’ key again and this time the screen wakes up again and switches to the login unlock screen. After I have entered my password the screen is now active again and I can restart firefox.
So i guess this points to a graphics issue rather than a CPU issue?
We already know this and we have contacted some high-ranking developers. But since the issue is selective (few people are having it) we can’t tell for sure what and why is going on.
1 Like
ok, thanks for the heads up. I hope you guys nail it.
Could it be related to this one, by any chance? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884116 . I reported this bug to Debian (hoping that this would get forwarded upstream, because this is more a kernel bug than a pure distribution issue), it seems that a few people have problems with some kernels on Intel graphics (i915). For me, using transparency themes really triggered the bug much faster…
@bavay the bug report says,
Reverting to linux-image-4.9.0-3-amd64 makes the problem go away.
did u try to downgrade your kernel?
For me, it did not work… I must say that I don’t understand Debian’s kernel numbering. I see lots of sub-versions and I had the feeling that some “new” 4.9.0-3 were also affected (since I still had the bug after reverting to a 4.9.0-3). But at least, now Debian kernel developers are working on it (a patch has been committed), so a new version that fixes this bug should come out.
a number of people on this post observed freezing screens when using firefox / playing videos. @mladen reported that someone at pursim also got a frozen screen while using firefox. Did you get the issue while using firefox?
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