Framework Laptop 13 Ryzen 7040 BIOS 3.05 Release and Driver Bundle

[Rei]

why is it called BETA? is it not a final release?

[Ulmondil]

@Rei

why is it called BETA? is it not a final release?

Explained here:

Framework 13 AMD Ryzen 7040 BIOS 3.03b BETA

Hi Everyone, We are waiting for one critical issue to release our next bios release for the AMD 13 and 16 bios. We integrated AMD updates as well as a Platform update from our bios vendor for this next release. We found during testing that the bios password would be cleared during the update if set. We have a checkpoint with the bios vendor mid week where we hope they have a fix for us to continue the internal validation and release process. We have confirmed that this upcoming release fixes …

[Matthew_Slade-Carter]

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.

[bak]

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

[tbd]

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)

[northivanastan]

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

[tbd]

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.

[Stebalien]

I’m seeing the same warning.

[Nathan_Ross]

Installed the new 3.05 bios update using lvfs on my framework 13 7840u mainboard. Update went flawlessly

[Muggle_Twist]

[   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

[dimitris]

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

[Gulfam_Rana_Amd]

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

[TheWiFiNerds]

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.

[TheWiFiNerds]

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.

[Muggle_Twist]

Arch Linux
Kernel: 6.8.2-arch2-1

I’ve downgraded back to 3.03 and the issue is no longer appearing

[Gulfam_Rana_Amd]

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

[TheWiFiNerds]

Interesting. Good test. My Arch dmesg is:

[user@arch ~]$ sudo dmesg | grep clocksource
[    0.023872] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370452778343963 ns
[    0.068679] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484873504 ns
[    0.085370] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2f7a4490637, max_idle_ns: 440795233661 ns
[    0.255382] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 6370867519511994 ns
[    0.392040] clocksource: Switched to clocksource tsc-early
[    0.403899] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[    1.427506] tsc: Refined TSC clocksource calibration: 3293.839 MHz
[    1.427529] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2f7a9082ad3, max_idle_ns: 440795296734 ns
[    1.427595] clocksource: Switched to clocksource tsc

grep tsc:

[user@arch ~]$ sudo dmesg | grep tsc
[    0.000000] tsc: Fast TSC calibration using PIT
[    0.000000] tsc: Detected 3293.759 MHz processor
[    0.085370] clocksource: tsc-early: mask: 0xffffffffffffffff max_cycles: 0x2f7a4490637, max_idle_ns: 440795233661 ns
[    0.392040] clocksource: Switched to clocksource tsc-early
[    1.427506] tsc: Refined TSC clocksource calibration: 3293.839 MHz
[    1.427529] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x2f7a9082ad3, max_idle_ns: 440795296734 ns
[    1.427595] clocksource: Switched to clocksource tsc

I’ll keep an eye on it.

[3by2]

What about 12th gen Intel?

[Mario_Limonciello]

People who have needed game mode or sg_display=0 for the white screen issue can you please back both of these out?

I would like to know if 3.05 fixed the issue.

[Michael_Marley]

I turned sg_display=0 off quite a while ago (maybe after upgrading to 6.8-rc? I can’t remember) and have had no issues.