We investigated this a while back, and fan speed reporting was not part of the ACPI specification. However it looks like this has been added recently with _FST!
https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/11_Thermal_Management/fan-device.html?highlight=fan
We will investigate if we can add this at some point in the future.
For now if you do want fan speed, we recommend grabbing this data using ectool, etc.
If youāre allowed custom modules (which requires a custom signing key with secure boot), I recently added fan control into Dustinās framework-laptop-kmod.
Hey Kieran, if you guys do get a chance to modify the ACPI thermal stuff, would you be able to lower the thermal trip points to something below 175Ā°C (448K)? Linux kernel 6.8 and above doesnāt like it otherwise.
Edit: Forum Thread: [RESPONDED] Firmware bug: ACPI table error causes missing sensors on Linux 6.7+ - #8 by Quentin
If the computer belongs to your company, better not to mess with it too much. If the computer is yours, itās a red flag that your company is effectively doing long-arm control over your own device
Sure! We will review this issue to see if we need to fix it in our next BIOS release.
In addition to fan speed data in the BIOS, I would love to have the ability to set, at the very least, a fan speed minimum in the BIOS, which can go up from there, of course. My preference is to use a fan at low RPM continuously to keep things a bit cooler whenever possible. I used to do this on my mac when it was supported via a third party app, but thatās not possible any longer to my knowledge.
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.
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).
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.