Just updated and did a quick test of S3 suspend/resume with Fedora 36 (mem_sleep_default=deep in kernel command line), all seems well.
Does fix #2 (capsule on disk) mean we’ll not need DisableCapsuleUpdateOnDisk=true going forward?
1 Like
Thanks! I love it!
1 Like
Upgrade worked well via LVFS on Fedora 37. Only thing is that no USB devices were detected on first boot after the upgrade. I had to shutdown the machine completely and keep it off for a few seconds, disconnect everything and re-connect after it was powered on again.
Also the Intel ME version does not seem to be patched with this update. The current version has security vulnerabilities:
Intel(R) CSME Version Detection Tool
Copyright(C) 2017-2022, Intel Corporation, All rights reserved.
Application Version: 8.0.1.0
Scan date: 2022-11-30 17:02:03 GMT
*** Host Computer Information ***
Name: framework
Manufacturer: Framework
Model: Laptop
Processor Name: 11th Gen Intel(R) Core(TM) i7-1185G7 @ 3.00GHz
OS Version: Fedora Linux 37 (Workstation Edition) (6.0.9-300.fc37.x86_64)
*** Intel(R) ME Information ***
Engine: Intel(R) Converged Security and Management Engine
Version: 15.0.23.1706
*** Risk Assessment ***
Based on the analysis performed by this tool: This system is vulnerable.
Explanation:
The detected version of the Intel(R) Converged Security and Management Engine firmware
has a vulnerability listed in one or more of the public Security Advisories.
Contact your system manufacturer for support and remediation of this system.
For more information refer to the Intel(R) CSME Version Detection Tool User Guide
or the related Intel Security Advisory list at:
https://www.intel.com/content/www/us/en/support/articles/000031784/technologies.html
In [RESPONDED] Firmware Security: CSME Version - #8 by ari, somebody shared a response from support indicating that 3.17 would not update the CSME to address these vulnerabilities, but that 3.18+ was planned to.
3 Likes
@Kieran_Levin, a quick clarification: does this update improve DP/HDMI power draw during suspend, or only when laptop is active? Thx.
@ssu Was hoping this would improve it so I did some testing.
BIOS 3.09:
BIOS 3.17:
Seems like suspend drain hasn’t changed. This is with 1 HDMI, 2 USB-A, and 1 USB-C cards.
6 Likes
Thanks for the data points, @feesh. That’s why I was asking @Kieran_Levin about the wording of the OP.
I did a smaller 3-hour test pre- & post-update on the Linux side with 1 DP + 3 USB C cards and found no difference in power draw. Still a 70% increase over 4 USB C cards.
Less scientifically, I think there was about 0.3 W improvement with the DP card inserted and the computer at resting state (10% brightness, WiFi on, same # of browser tabs and apps/windows open).
But as we’ve all noted, it’s the draw during suspend of the non-USB C cards on the 11th gen machines that’s a real battery-life killer - especially compared to competing laptops. If I’m going to be plugged, then I don’t mind keeping a non-USB C card inserted.
1 Like
Since I installed 3.17 a few days ago, I’ve been having some intermittent charging/battery issues.
Just now, my battery was at 50% and the laptop was plugged in. I unplugged the charger, and the battery immediately dropped to 2%, forcing the laptop into sleep mode. Upon plugging the charger back in, the battery immediately jumped back up to 51%. I then unplugged the charger and the battery stayed at 51%.
Also, this morning when I went to turn on my laptop, it immediately shut off due to low battery (which I thought was weird considering it was about half full last night). So, I plugged it in, and when it booted the battery said 60%.
Sleep seems to be worse on Fedora for me? Might just be not enough testing though. >30% drain in 6 hours of sleep (and me sleeping). Windows is also entering hibernate a lot faster, I’ll run sleep study later.
Thank you for continuing to support the 11th gens!
Update went smoothly on F37 with fwupd.
No glaring issues yet, but there are still a few more things for me to play around with.
Looking forward to future fixes 
Updated mine 11th Gen i5 on Fedora 37 using fwupd. No issues yet, and it went smoothly.
3 Likes
I am using Arch Linux. I set the charge limit to 80% immediately after installing the update (as well as disabling the fingerprint reader and PS2 mouse emulation) but otherwise did not adjust any BIOS settings. I did try powering off completely, but the issue hasn’t happened apart from the two instances I mentioned, so it’s hard to say for sure if that helped. I’ll definitely post here if it happens again.
1 Like
Another report:
3.10 (3.16) → 3.17 from Fedora 36 LVFS. Update went smoothly (updating from 100% plugged in worked. NVRAM boot variables were reset, so I had to re-setup those.)
Shortly after, I updated to Fedora 37. All seems fine so far.
Thanks!
I tried to enable testing but it is failing to refresh:
(fwupdmgr:4789): Fwupd-DEBUG: 13:18:22.217: downloading https://cdn.fwupd.org/downloads/firmware-testing.xml.@compression@.jcat
(fwupdmgr:4789): Fwupd-DEBUG: 13:18:22.218: Emitting ::status-changed() [downloading]
Downloading… [ \ ](fwupdmgr:4789): Fwupd-DEBUG: 13:18:22.359: download progress: 88%
(fwupdmgr:4789): Fwupd-DEBUG: 13:18:22.359: download progress: 88%
Downloading… [********************************** ](fwupdmgr:4789): Fwupd-DEBUG: 13:18:22.359: download progress: 100%
(fwupdmgr:4789): Fwupd-DEBUG: 13:18:22.359: download progress: 100%
(fwupdmgr:4789): Fwupd-DEBUG: 13:18:22.359: download progress: 100%
(fwupdmgr:4789): Fwupd-DEBUG: 13:18:22.359: download progress: 100%
(fwupdmgr:4789): Fwupd-DEBUG: 13:18:22.359: Emitting ::status-changed() [idle]
(fwupdmgr:4789): Fwupd-DEBUG: 13:18:22.359: status-code was 404
Downloading… [***************************************]
Failed to download, server response was 404
running on openSuse Tumbleweed
sudo fwupdmgr --version
runtime org.freedesktop.fwupd 1.8.7
runtime org.freedesktop.fwupd-efi 1.0
runtime com.hughsie.libjcat 0.1.12
runtime com.dell.libsmbios 2.4
compile com.hughsie.libjcat 0.1.12
runtime org.kernel 6.0.10-1-default
compile org.freedesktop.gusb 0.3.10
compile org.freedesktop.fwupd 1.8.7
runtime org.freedesktop.gusb 0.3.10
With the “testing” remote enabled in my fwupd configuration I got the 3.17 BIOS installed last night. The Gnome “Software” app saw it and did the install for me(Fedora 37). So far so good. Per the usual I went into the bios afterward to reconfigure the charging limit.
Successful update from 3.10 to 3.17 in EndeavourOS (arch linux) via fwupdmgr. As usual, NVRAM got erased, but having rEFInd in my EFI fallback boot location ( esp/EFI/BOOT/BOOTX64.EFI ) meant that I did not even have to do the F3 trick to chainload my original rEFInd installation.
Since I upgraded the BIOS to 3.10 I also upgraded Fedora to 37. I just booted up with the latest kernel from Starting this morning after the F37 upgrade I noticed this new error (first time in updates-testing, 6.0.11-300.fc37journalctl during the past year):
[ +0.052642] ACPI BIOS Error (bug): Could not resolve symbol [\_TZ.ETMD], AE_NOT_FOUND (20220331/psargs-330)
[ +0.000006] ACPI Error: Aborting method \_SB.IETM._OSC due to previous error (AE_NOT_FOUND) (20220331/psparse-529)
Nothing seems obviously broken, but I don’t know how to interpret these ACPI errors.
@feesh have you tried doing a full bios reset after the update? I don’t fully remember the process, it’s on here somewhere, you do a battery disconnect in the bios and then physically unplug the battery and plug the charger in and then the lights blink red you can plug things back in and boot… anyways when I updated from 3.07 to 3.10 the battery drained like crazy still, but after the reset I mentioned above things where fixed. This may help with the update to 3.17 as well, just a thought.
1 Like