The third party app for framework is fw-fanctrl
Unfortunately, that’s for Linux only. I’m on Windows 11 on my Framework laptop.
I have a different type of problem related to sleep happening since my update to 3.05: the system shuts itself off and restarts when in sleep.
Here’s the log of the most recent time, you’ll see it enters suspend, and then the next log entry some time later is a boot:
Apr 24 02:46:03 thebelt systemd[1]: Reached target sleep.target - Sleep.
Apr 24 02:46:03 thebelt systemd[1]: Starting systemd-suspend.service - System Suspend...
Apr 24 02:46:03 thebelt rtkit-daemon[1400]: Successfully made thread 2704 of process 2678 owned by '1000' high priority at nice level 0.
Apr 24 02:46:03 thebelt rtkit-daemon[1400]: Supervising 1 threads of 1 processes of 1 users.
Apr 24 02:46:03 thebelt rtkit-daemon[1400]: Supervising 0 threads of 0 processes of 1 users.
Apr 24 02:46:03 thebelt rtkit-daemon[1400]: Supervising 0 threads of 0 processes of 1 users.
Apr 24 02:46:03 thebelt rtkit-daemon[1400]: Successfully made thread 2704 of process 2678 owned by '1000' RT at priority 20.
Apr 24 02:46:03 thebelt rtkit-daemon[1400]: Supervising 1 threads of 1 processes of 1 users.
Apr 24 02:46:03 thebelt systemd-sleep[53256]: Entering sleep state 'suspend'...
-- Boot 8e89f97032a34dd5b96a07ea43b82b11 --
Apr 24 03:00:52 thebelt kernel: Linux version 6.5.0-28-generic (buildd@lcy02-amd64-001) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.41) #29-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 28 23:46:48 UTC 2024 (Ubuntu 6.5.0-28.29-generic 6.5.13)
This is entirely while plugged in.
The first time I noticed this happening was a couple days ago and the logs show that the time it spent actually suspended (or at least, until restarting) was substantially longer, about 10 hours:
Apr 21 03:38:10 thebelt systemd[1]: Reached target sleep.target - Sleep.
Apr 21 03:38:10 thebelt systemd[1]: Starting systemd-suspend.service - System Suspend...
Apr 21 03:38:10 thebelt rtkit-daemon[1320]: Successfully made thread 2292 of process 2267 owned by '1000' high priority at nice level 0.
Apr 21 03:38:10 thebelt rtkit-daemon[1320]: Supervising 12 threads of 7 processes of 1 users.
Apr 21 03:38:10 thebelt rtkit-daemon[1320]: Supervising 11 threads of 6 processes of 1 users.
Apr 21 03:38:10 thebelt rtkit-daemon[1320]: Supervising 11 threads of 6 processes of 1 users.
Apr 21 03:38:10 thebelt rtkit-daemon[1320]: Successfully made thread 2292 of process 2267 owned by '1000' RT at priority 20.
Apr 21 03:38:10 thebelt rtkit-daemon[1320]: Supervising 12 threads of 7 processes of 1 users.
Apr 21 03:38:10 thebelt systemd-sleep[101850]: Entering sleep state 'suspend'...
-- Boot 0936dabd85084554bced3419099862af --
Apr 21 13:48:57 thebelt kernel: Linux version 6.5.0-28-generic (buildd@lcy02-amd64-001) (x86_64-linux-gnu-gcc-13 (Ubuntu 13.2.0-4ubuntu3) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.41) #29-Ubuntu SMP PREEMPT_DYNAMIC Thu Mar 28 23:46:48 UTC 2024 (Ubuntu 6.5.0-28.29-generic 6.5.13)
I don’t 100% know this is down to the update but it’s certainly the last thing I’d changed.
Edit: upon looking a little closer maybe it never really sleeps properly in those cases? Successful sleeps that don’t do this have lines like
Apr 24 08:08:39 thebelt kernel: PM: suspend entry (s2idle)
Apr 24 08:08:39 thebelt kernel: Filesystems sync: 0.001 seconds
and a few more after the “Entering sleep state ‘suspend’” line.
1 Like
It’s a pretty common requirement nowadays(alongside full disk encryption) for employees that keep sensitive data(or means to access them) on their devices. At least it is in Europe (see GDPR and other data protection laws).
I have secure boot enabled but I use the unlockdown module to temporary relax kernel lockdown. I’m not sure about the security implications.
Superb, thank you!
I’ve been assessing read-only ectool access so security compromises don’t have to be made to run it. So far, no luck. ectool does feel like a workaround at best.
Exposing common system data (like fan speed) via acpi will benefit all FW owners regardless of OS.
Cool, thanks for the alternate option!
FW Team, any thoughts on pulling this upstream into the suggested Ubuntu linux-oem-22.04d kernel as well as for supported Fedora versions?
Yup, these requirements have been standard for about the past decade among various jobs & contracts I’ve worked.
Thanks, this is another possible workaround. May have to run it through some testing to see if it passes or fails systems security policy.
I was just proposing in DHowett’s thread that it’d be ideal if Framework, as a company, could use their EV certificate to code sign the EC kernel-mode driver on Windows such that it can pass secure boot. Currently, you cannot use ectool on Windows without enabling test signing and disabling secure boot, which is not ideal.
Please also check this other thread where we’re discussing the pulsating on/off fan behavior and how it could be improved in the EC.
So does Linux (or something in userspace?) support the new z-states functionality? I’m still not entirely sure whatit does, anyone have more detail on how this benefits e.g. regular S3 suspend on Linux?
If it helps I’ve started making a Python library that doesn’t require ectool. But I have forgotten to mention that both that and framework-laptop-kmod require a working cros_ec_dev with Dustin’s framework laptop patches. But it shouldn’t be a problem for Linux 6.10 (though ectool should work too then).
Edit: I just thought while most of the EC requires a request and response, the fan speed is present in a memory mapped area, so it might be possible to read only, but I’m not sure.
Edit 2: From what I can find ioperm (the syscall that gives me permission to go near the port) is also locked down, but I did write a python script to try anyway.
Sadly(?) I had to go back to 0.3.3, cause after 0.3.5 I found some issues while playing video (happened in youtube with firefox and local video with mpv). I think it has something to do with vaapi because I use it in both. It’s very hard for me to debug because after the crash I could not interact with the computer. I had a terminal open but running any command failed, I couldn’t also login in the tty, just managed to see an error regarding failing I/O but no idea what was it. That plus the fact that the sleep is misbehaving again made me to go back to 0.3.3 that has worked without issues for me.
For context: I’m using latest hyprland in nixos stable.
There was this bug when playing vp9 content with hw decode vaapi vp9 decoding glitches on rembrandt [Reproducer in comments] (#8044) · Issues · Mesa / mesa · GitLab. Should be limited to vp9 and bios version shouldn’t matter but maybe it’s related. Still my advice is to ensure the amdgpu firmware versions of your distro are up to date with the linux-firmware upstream repo, it’s won’t hurt.
I can reproduce the issue with an Ubuntu 24.04 live image released yesterday, on my Framework 13 AMD 7040U, BIOS release 3.05:
2024-04-26T10:03:24.166681+00:00 ubuntu kernel: ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)
2024-04-26T10:03:24.166681+00:00 ubuntu kernel: ACPI: thermal: [Firmware Bug]: No valid trip points!
2024-04-26T10:03:24.166682+00:00 ubuntu kernel: ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)
2024-04-26T10:03:24.166682+00:00 ubuntu kernel: ACPI: thermal: [Firmware Bug]: No valid trip points!
2024-04-26T10:03:24.166682+00:00 ubuntu kernel: ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)
2024-04-26T10:03:24.166683+00:00 ubuntu kernel: ACPI: thermal: [Firmware Bug]: No valid trip points!
2024-04-26T10:03:24.166683+00:00 ubuntu kernel: ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)
2024-04-26T10:03:24.166683+00:00 ubuntu kernel: ACPI: thermal: [Firmware Bug]: No valid trip points!
@Kieran_Levin , what is the effect of this failure? Is temperature control working, or would I risk overheat damage? Can you recommend upgrade to Ubuntu 24.04 right now, or rather wait for a fix?
I’m not Kieran (or anyone important here), but AFAIK not much, the EC still controls the fan speed and anything related to thermal control, so there should be no risk of overheating. The main effect is that the ACPI temperature sensors no longer appear in lm-sensors if you wanted to monitor it yourself, but I’ve fixed that for kernel 6.9.
Basically ACPI allows for 4 different trip points: passive, active, hot, and critical. The first 2 aren’t implemented on framework laptops, but they let Linux take action based on the set thermal governor (usually fan control or throttling), I just spent a while looking at what the kernel does with hot and it seems it just does nothing(?), and Linux will emergency shutdown (a clean shutdown with a power off timer) for critical trips. However those trip points were set to incredibly high values that the laptop would’ve been long gone by the time they tripped (190°C hot, 210°C critical), and only recently has Linux (kernel 6.8) implemented a warning for that (175°C max).
But I’m just a CS student so idk how things work.
That one was fixed to me with linux-firmware-20240312 The problem I faced with 0.3.5 was not even with vp9 videos, but unfortunately, I can’t reproduce it at will and when it happened and I had a terminal opened I couldn’t even interact with the terminal. So I went back to 0.3.3 at least till the sleep issue is fixed in the kernel for 0.3.5 (or 0.3.7 fixes it in BIOS level).
1 Like
Thanks @Steve-Tech ! To confirm in my words: thermal protection is not degraded when upgrading to 24.04. Previously ineffective hot and critical trips due to unrealistic values just remain ineffective and are disabled.
Had noticed your fix (thanks so much!), but wondered whether it is critical to wait for it to propagate into Ubuntu release kernel. Either by Ubuntu upgrading to 6.9, or your fix being back ported to 6.8. It sounds like we don’t need to hold upgrade until then.
It is my daily driver but I primarily use Windows 11 (for my job).
The root cause is a pretty critical systemd/linux kernel oversight that has always existed. Its a race condition. Linux kernel passes off control to the init system (systemd) before all the drivers have initialized. That part is normal. Hardware is so fast now that systemd ends up finishing all pre-GUI services and starts sddm (I use KDE Plasma) before the amdgpu kernel driver has finished initializing. This results in a black screen the lasts forever as sddm doesn’t see the amdgpu driver available to start on. This won’t happen on GDM as it waits for the display drivers to finish initializing before attempting to start. More detail at the bug report Bug #2063143 “Frequent boot to black display” : Bugs : Linux and the other bug reports linked there.
This issue can occur on any device and I also experience the same issue on my HP Spectre x360 (Intel i7-6500U). For whatever reason the issue became exacerbated in ubuntu’s linux kernel 6.8.
Hello, is it normal if ubuntu offert me automatic update for Bios in ubuntu software ?
Correct! Thermal protection is effectively completely unaffected by the kernel version.
I doubt it’s critical enough be to backported, although it is technically a regression so maybe, but I feel like it would’ve happened already if it was.
Yes, both the Gnome store and KDE store have fwupd backends, and can update firmware.
I prefer the command line way incase something goes wrong I feel more familiar, but there shouldn’t be any issues upgrading through the store.
1 Like
I’m experiencing this same problem… it’s really concerning. Fedora 40, happens with both KDE and GNOME. It happens after a few hours of usage usually.
Concerningly, nothing weird gets logged to journald. Also, at some point, I had a swapfile, and in one of these freezes I got to a TTY and it read Read-error on swap-device. Considering the abstence of journald logs, this swap error and the fact that it would seem as I lost a few minutes of stuff on the next boot, it would seem that there’s an issue with the SSD. I’ll roll back to 3.03 and report back (otherwise, feel free to ping me.)
1 Like
I also didn’t see anything in the logs. I’m scared to try again, so I’ll probably stay on 3.03 for the time being since there’s no compelling reason to upgrade - 3.03 works just fine.