For anyone running F40 nighties/beta - the bug is still present also as libxmlb which needs to be 0.3.18 isn’t pushed to testing (0.3.17) and the 0.3.15 available is also bugged
I was on 3.03 beta and fwupdmgr wasn’t happening for me on f40 beta as above so gave in and did the FAT32 usb stick upgrade, need to unpick the sg_display bits next.
I’m wondering once f40 goes platinum/not beta I’ll do a fresh install… not really sure what I’ve done to this install now…
you need to enable updates-testing.repo and install the 0.3.18 libxmlb rpm from that. And then delete the cache directory and reboot it should pick it up after that.
Just updated to 3.05 and I also see the same error(s) in dmesg.
[ 1.016817] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 1.016837] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003, bcdDevice= 6.06
[ 1.016839] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.016840] usb usb2: Product: xHCI Host Controller
[ 1.016841] usb usb2: Manufacturer: Linux 6.6.21-gentoo-x86_64 xhci-hcd
[ 1.016842] usb usb2: SerialNumber: 0000:c1:00.3
I also see this for usb4, usb6, and usb8. A total of 4 times, same as the number of physical ports.
But other than pollution in the log I haven’t [yet] observed any issues with the ports.
1 Like
Not sure if my issue is caused by this BIOS update or a MESA, linux kernel, or linux firmware change but I am getting frequent black screen on boot now on the internal display on Ubuntu Noble 24.04. It seems to occur about 20-50% of the time.
I had not experienced a single black screen on boot prior to applying this BIOS update. I have been using Ubuntu Noble development for months now.
These are normal informational messages likely you’re seeing them due to a kernel update. These have been present in any recent kernels for a while and it’s just extra reporting that was either suppressed or ignored in prior kernel versions. They are present on 6.9 series too if that makes you feel any better.
The fingerprint reader update fails with: failed to req: transfer timed out.
$ fwupdmgr update
Devices with no available firmware updates:
• WD BLACK SN850X 1000GB
╔══════════════════════════════════════════════════════════════════════════════╗
║ Upgrade Fingerprint Sensor from 01000330 to 01000334? ║
╠══════════════════════════════════════════════════════════════════════════════╣
║ Fix physical MITM vulnerability that was found from blackwinghq - a touch ║
║ of pwn part 1. ║
║ ║
║ Fingerprint Sensor and all connected devices may not be usable while ║
║ updating. ║
╚══════════════════════════════════════════════════════════════════════════════╝
Perform operation? [Y|n]:
Writing… [ ]
failed to write: failed to req: transfer timed out
I tried powering off the laptop and waiting a few minutes before restarting, but neither seemed to have worked.
p.s. This update comes from the regular lvfs repo and I’m using the latest fwupdmgr in Fedora 39.
EDIT: Welp right after writing this post the update worked.
Successful Manjaro update from 3.03 to 3.05. Running kernel 6.8.5-1 and everything appears to be working properly. Almost no errors in the journal and I notice my average power consumption’s dropped by a couple of watts.
When i try to update to 3.05 i just get a black screen and when reboot it say error 2 decompress failed
On Windows 11, and just updated to BIOS version 3.05 using the utility, was successful and have no issues.
On Fedora 39 and also just received BIOS version 3.05 through the Software app. The update was successful. I’ll continue testing to see if there are any regressions (hopefully none!)
I updated this morning, and it seems to have changed the fan behaviour which I haven’t found a way to work around yet. When adding a little load my CPU temperature rises up to 100°C, but the fans are not really kicking in, only producing a light blow. Consequently, the cpu gets throttled down.
I am on Arch and using the power-profiles-daemon as recommended by Framework Laptop 13 - ArchWiki
I have set the fan speed to autocontrol via ectool.
I’m observing the same issue (PPD, no manual ectool changes) but not sure if BIOS related. The fan will eventually ramp up but it will take a long time to start let alone reach peak RPM. Once it does temps stay around 95C at 3.6GHz all-core load.
I ran the following 3 times to confirm:
- Wait for CPU idle temp to stabilise (39-40C in my case)
- Run all core CPU load with stress, i.e.
stress -c 16and start timer.
CPU will shoot up to about 4.2GHz and 100C then start to throttle down to about 3.1 GHz. Fan does not ramp up at any audible level until about 35 seconds in. It will then [very] gradually ramp up every 5-10 seconds until it reaches a peak about 1m20s into the test. With more airflow core frequency will also increase a bit more to about 3.6GHz.
Needless to say, this is extremely sluggish fan behaviour.
Edit:
Some further investigation:
- fan barely audible at 100% single core load at 4.8GHz sustained with temps in the 98.9 - 99.5C range; I would expect the fan to be at max RPM with these temps;
- no difference if PPD is running at all or not;
- no difference between
amd_pstatemodes, thoughamd_pstate=guideddoes seem to at least keep the CPU temps at bay a bit better in all-core loads while the fan eventually wakes up from slumber and decides to slowly ramp up;
If there’s a BIOS rollback procedure I’d be happy to dig into it and compare. Ditto re the informational USB messages mentioned earlier which, I admit, may have already been there before and only just noticed by actively looking for them.
1 Like
This has been my experience as well. Dunno if it is intended or if it is indeed a regression of some sort.
I’ve just had a look at my desktop workstation, which is AM5 based, and the We don't know the algorithms for LPM for this host, disabling LPM. info message in dmesg is also showing.
Obviously, It’s not a like-for-like comparison, but I’m far more inclined now to think that this is completely unrelated to the FW 3.05 BIOS release and was likely there even with 3.03. So no need for anyone to worry about seeing it in the logs.
Have had no issues with the new BIOS under Debian Sid.
2 Likes
Have you, or could you (please), run a stress test keeping an eye on CPU temps and fan? Just curious how your fan behaves. It might help in diagnosing if this is an isolated issue and, if so, if it’s hardware/distro/BIOS related.
I’m having trouble updating my amd 13 BIOS from 3.03 to 3.05 using the EFI shell update, following the instructions here. I’ve downloaded the correct BIOS zip (Framework_Laptop_13_Ryzen7040_BIOS_3.05_efi.zip)
and
extracted it to a 10GB FAT formatted USB,
unmounted,
reboot into BIOS,
disabled secure boot,
boot from file,
navigated toefi > boot > bootx64.efi
executed and let the terminal run automatically
immediately receive the errorupdate.nsh not recognized as an internal or external command, operable program or script file
what can I do from here?
I was about to update the same way as you, until I read that running the script might delete your UEFI bootloader entries making your system unbootable if you don’t know how to recreate them.
Honestly I wanted to save myself the trouble, so I just enabled the “testing” repo of fwupd and it found the update at that point. Install went well (it also found a fingerprint reader firmware update). Just revert back to the stable repo of fwupd after rebooting, to make sure you’re not accidentally installing beta firmware in the future. 
fwupdmgr enable-remote lvfs-testing
And once you are done:
fwupdmgr disable-remote lvfs-testing
2 Likes
The 3.05 BIOS is out of beta and has been released for GA. You don’t need lvfs-testing anymore. Running just
fwupdmgr --force refresh
should suffice.
1 Like