Are the checksums posted anywhere other then this forum? I would like to cross reference them to make sure it is the real checksum. Maybe on GitHub, FW socials? Posting in one place doesn’t isn’t the most secure method, especially with bios updates. Would be even better if they were signed.
2 Likes
Cross posting in case it’s helpful: Hibernation used to work but stopped working some weeks ago (AMD13). Suspend works fine. The hibernation problem persists after updating to the new BIOS (3.05). The screen goes black, then is restored, but neither mouse nor keyboard respond, and only shutting down by long power button press and restarting works.
3 Likes
Indeed. I have the same problem (affects Modern Standby when Windows decides to hibernate after a period of battery drain).
@Kieran_Levin I just updated (LVFS). All seems good so far (just minutes into the new BIOS) but it also brought back a wake-back-up-on-lid-close issue that’s almost (not 100%) identical to the original report in this old thread:
- All done while plugged in to dock (also provides power).
- Suspend using power button.
- Close lid.
- Machine immediately wakes up.
The only change here was the BIOS+EC update, everything else stayed the same: Fedora 39 on 6.7.11-200.fc39.x86_64.
That original issue above had been worked around at the time with a udev rule:
$ cat /etc/udev/rules.d/20-framework-suspend-fixes.rules
# Disable wakeup from spurious keyboard event caused by power (un)attach (working around FW EC bug).
ACTION=="add", SUBSYSTEM=="serio", DRIVERS=="atkbd", ATTR{power/wakeup}="disabled"
but that hadn’t been necessary for some time now as a kernel workaround rolled out (for Fedora IIRC it was backported during the 6.6 series) so I had disabled it then.
Re-enabling the udev rule mitigates this for me with BIOS 3.05. The only “loss” (if you can call it that) is that the power button no longer pulses while sleeping after the lid is closed. No biggie, just a little side loss (or benefit for some I guess).
There’s FW/AMD things brewing upstream:
https://bugzilla.kernel.org/show_bug.cgi?id=218641
has anything that sorta-reverted that earlier kernel workaround been backported to stable kernels?
ccing @Mario_Limonciello and @Matt_Hartley here I suppose.
3 Likes
I did the update. Boot up and the system operates seemingly ok. One improvement tested: Can close the lid and open again and the system stays on instead of turning completely off.
CLI tool displays correct new version info (3.05).
However, when I went back to turn off booting from USB in the bios options, password I used before now no longer works. Used to show when typing up to 10 characters, now there is 64 character p/w indicator. I can’t edit bios anymore. I’m pretty sure I’m not mistyping or leaving all caps on, or something like that. Even walked and took a few hours break before trying again.
How screwed am I?
4 Likes
It only applied to BIOS 3.03 as we were anticipating it fixed in next BIOS. I guess we need to extend the quirk to this BIOS too if this goes to stable.
Kieran mentioned it in known issues above; it’s still being investigated.
I’ve noticed since upgrading sometimes my caps lock is wrong.
5 Likes
Excellent work. Thank you very much for the very informative post and detailed recap. I appreciate you all keeping your word to include the hashes, and really make this release very smooth and professional; with bonus transparency on what’s next.
Excellent testing and feature deployment, very impressive turnaround. This was much needed, and framework delivered on all counts.
You can extract the exe using 7-zip and just update the stuff you want in device manager.
1 Like
Perhaps you can try rolling back to 3.03 BIOS with the 3.03/3.03B package?
I should have thought about that - thanks!
why is it called BETA? is it not a final release?
Explained here:
2 Likes
Installed the 3.05 BIOS yesterday and updated the drivers for the fingerprint sensor, audio and USB ethernet.
All installed OK but since then I’ve been getting IRQL_NOT_LESS_OR_EQUAL BSOD, had three this morning.
WhoCrashed gives the following info for all three crashes:
| Crash dump file: | C:\Windows\Minidump\040524-18078-01.dmp (Minidump) |
|---|---|
| Bugcheck code: | 0xA(0x469F6AC34C, 0x2, 0x0, 0xFFFFF804188B8247) |
| Bugcheck name: | IRQL_NOT_LESS_OR_EQUAL |
| Bug check description: | This indicates that Microsoft Windows or a kernel-mode driver accessed paged memory at DISPATCH_LEVEL or above. This is a software bug. |
| Analysis: | This is a typical software problem. Most likely this is caused by a bug in a driver. |
I’m suspecting one of the newer drivers over the BIOS update so I’ll roll back one at a time to see which causes the issue.
3 Likes
Appreciate the update!
Is it really necessary to remap the framework keyboard button though when installing the bundled drivers? I’m sure everybody who is installing this driver bundle already has your site bookmarked 
Can someone confirm if this message still shows up in dmesg?
ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20230628/tbfadt-615)
1 Like
Shows up on every boot for me on Debian Testing, both before and after upgrading, and has for most of the time I have owned a FW13, don’t remember when I first noticed it
I don’t think it’s that serious, unless it has something to do with the suspend issues I have been experiencing
Seems to be a 1-bit off in the FADT. Maybe this can be fixed simply by set the length to 0 in the firmware blob.
2 Likes
I’m seeing the same warning.
Installed the new 3.05 bios update using lvfs on my framework 13 7840u mainboard. Update went flawlessly
[ 53.034015] clocksource: timekeeping watchdog on CPU9: Marking clocksource 'tsc' as unstable because the skew is too large:
[ 53.034041] clocksource: 'hpet' wd_nsec: 503521397 wd_now: 2d3429b2 wd_last: 2cc6278c mask: ffffffff
[ 53.034050] clocksource: 'tsc' cs_nsec: 503938837 cs_now: 34ac7212b8 cs_last: 344982513c mask: ffffffffffffffff
[ 53.034056] clocksource: Clocksource 'tsc' skewed 417440 ns (0 ms) over watchdog 'hpet' interval of 503521397 ns (503 ms)
[ 53.034063] clocksource: 'tsc' is current clocksource.
[ 53.034080] tsc: Marking TSC unstable due to clocksource watchdog
[ 53.034113] TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'.
[ 53.034116] sched_clock: Marking unstable (53107777585, -71453794)<-(53037557229, -3448833)
[ 53.036761] clocksource: Checking clocksource tsc synchronization from CPU 6 to CPUs 0,2-4,9,11,13,15.
[ 53.037075] clocksource: Switched to clocksource hpet
From dmesg
TSC appears to be broken on this BIOS for me shortly after boot