It looks like you were right! The udev rule described here seemed to do the trick for me: Framework Laptop 13 Ryzen 7040 BIOS 3.05 Release and Driver Bundle - #14 by dimitris.
Thanks for the suggestion, @Mario_Limonciello!
2 Likes
That’s rough. Hope you find a tenable solution pronto.
Not sure if this is your daily driver. I’ve booted from an usb drive to have a running system and access my files while dealing with issues.
I’ve found this line is a good balance of performance/cost/space/size.
Thanks, I was checking out ectool & fw-fanctrl, however disabling secure boot breaks company policy at my job, so I haven’t run them.
I would be ecstatic if FW provided fan speed data via the next BIOS update.
It’s cool how both Asus and Gigabyte’s systems reveal this via the it87 module.
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.
4 Likes
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.
3 Likes
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.
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?