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.
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:
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.
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)
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.
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
Hmm, which distro/kernel? This is on Fedora 39 and 6.8.4-200.fc39.x86_64:
$ journalctl -k -b --no-hostname |egrep 'TSC|clocksource|unstable'
Apr 04 20:24:00 kernel: tsc: Fast TSC calibration using PIT
Apr 04 20:24:00 kernel: clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1910969940391419 ns
Apr 04 20:24:00 kernel: clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns
Apr 04 20:24:00 kernel: clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2f7ab06e5b4, max_idle_ns: 440795345792 ns
Apr 04 20:24:00 kernel: clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 1911260446275000 ns
Apr 04 20:24:00 kernel: clocksource: Switched to clocksource tsc-early
Apr 04 20:24:00 kernel: clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
Apr 04 20:24:00 kernel: tsc: Refined TSC clocksource calibration: 3293.811 MHz
Apr 04 20:24:00 kernel: clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2f7a758b259, max_idle_ns: 440795268702 ns
Apr 04 20:24:00 kernel: clocksource: Switched to clocksource tsc
Apr 04 20:24:26 kernel: kvm_amd: TSC scaling supported
After only installing the gpu drivers from here, it showed that I only have 448mb dedicated graphics memory on my Ryzen5, I’m unsure but in my previous windows install with the older drivers I think that used to be like at 600-700mb
You can change it to game mode in UEFI/BIOS and it will reflect as 4000MB? Is that preferred?
I thought it was only 256MB in non game mode but I am not certain.
Looks like it may be kernel related as there seems to be a recent increase in folks on other distros as well completely unrelated to framework seeing it as well…
I confirmed the issue is not present in Arch after running the system 16 hours or so.
Arch Linux
Kernel: 6.8.2-arch2-1
I’ve downgraded back to 3.03 and the issue is no longer appearing
I had it off for a second and those were the values I think, but I do have it on right now and all the time normally