Framework Laptop 13 Ryzen 7040 BIOS 3.17 Release STABLE

Framework Laptop 13
,
21

Not sure if this is at all relevant, but the AMD PPR for this generation states that:

the TSC increments at the rate specified by the P0 Pstate.

The P0 Pstate is effectively the same as the base clock, so it should be approximately 3300MHz for a 7840U, or 3500MHz for a 7640U. (The Linux kernel runs a little benchmark to figure out the frequency, so it usually isn’t exact.)

My laptop with a 7840U just gave me 3293.811MHz, which seems to be over 1850 ppm off the target, and that seems like a lot, if I’ve done my math right.

22

The user should not ask Microsoft what piece of software they are allowed to use on their own computer, thus, “smart app control” should be turned off by the user.

What was the CPU power during the test? Different methods of benchmarking or stress testing may yield different results. For example, “Stress FPU” gets higher temperatures at the same CPU usage percentage or clock speed.

23

No idea, but this number was taken from dmesg | grep tsc, and the tsc module does its benchmark very early in the boot process well before the other cores are brought online, and I believe before the other Pstates are properly enabled. (it does refine it later but I’m not counting that.)

Edit: Sorry I just realised what you were asking, Linux’s benchmark simply compares TSC ticks with the PIT, and shouldn’t be affected by power usage, Pstates, instruction clocks, or anything else.

24

My apologies if this question is stupid but, do I need to update my BIOS if I’m on the 3.17 BETA release?

25

This post was renamed from BETA to STABLE, and the SHA’s haven’t changed. So you shouldn’t need to update again, as it’s the same file.

3 Likes
26

I also got an issue, where my keyboard intermittently have some key that do not work : right arrow key, and brightness up (F8). I also manage today to fix this issue by adding

i8042.notimeout

to the kernel parameters.

On debian, you can do this, by adding i8042.notimeout to the file /etc/default/grub at the line GRUB_CMDLINE_LINUX="i8042.notimeout”

and then update-grub.

3 Likes
27

I see you edited to remove the suggestion to blacklist the cros_ec_lpcs module to fix the “TSC unstable, switched to HPET” … that would be very surprising if it worked, but worth a try … and yeah, it doesn’t help, in my testing, tsc still unstable.

Side note, I do blacklist some other “cros” modules, in order to somewhat fix the cpu-temp-sensor read error. Kind of a long story, and it’s always been a problem I think, but basically sudo ectool temps all will sometimes show:

cpu@4c                311 K (= 38 C)           0% (333 K and 368 K)

and sometimes:

Sensor 3 disabled

At some point cros_ec_hwmon added support for these sensors, so they showed up in lm-sensors output, and I had a status-area widget polling sensors every couple seconds, and this made that temp sensor never work, and also the fan didn’t respond to real CPU temp during this period. But blacklisting this module, to remove the sensor from lm-sensors output, made it usually work again for ectool temps all and for the built-in fan control. (And then I removed the status-area widget too.)

More recently, I noticed it was seemingly always “disabled” again, and that these temp sensors show up in lm-sensors output again (via acpi rather than the cros_ec_hwmon), and I haven’t figured out how to disable that, but I found that blacklisting a bunch of other “cros” modules that I don’t seem to need (cros_ec_sysfs, cros_ec_debugfs, cros_kbd_backlight, gpio_cros_ec) seems to make it mostly work again? Could be luck/placebo but my theory is that this was always caused by lots of traffic on the i2c bus, causing that sensor to glitch, so reducing integrations that enable polling misc little things on the i2c bus enables it to usually work.

Well that was quite a tangent. Anyway, Framework, wishlist firmware issues: TSC unstable, “cpu@4c” sensor unreliable. But I imagine these are quite tricky and unlikely to be fixed directly by framework any time soon (may require deep investigation of AGESA and SMM behaviors for the TSC unstable, and creative solutions for i2c bus locking/sharing and caching cpu temp sensor reading).

1 Like
28

Hi, Yes i edited my post, because blacklisting the cros_ec_lpcs was definitely not the way to fix the issue with the tsc. I still think the issue is related to the EC and made progress this morning.

I found that i have a quickly repeating log in /sys/kernel/debug/cros_ec/console_log with “Sustainer disabled” in it. So, I fix a limit for the battery charge in bios at 80%. It seems to calm down the EC logs, which may have produce a lot of SMI previously.

I will see if its better regarding the tsc instability and continue posting my progress here.

29

Regarding this issue I tried this patch on my end (Needed on kernel <6.11 TSC fix)
which worked (however, note I’m still on BIOS 3.05, currently running 6.18.1 I no longer run into any issues without the patch, I will most likely update to 3.17 by the end of Febuary and report how it goes running it)

30

Hi, a really interesting patch, but i already have it as i’m using kernel 6.12.63. So I finally use tsc=reliable in my kernel parameters.

My issue with my keyboard (RIGHT arrow and BRIGHTNESS_UP working intermittently) seems to be cause by the EC being overwhelmed by something so i’m currently trying a change in the UPower config file /etc/UPower/UPower.conf

NoPollBatteries=true

which seems to be giving good results (combined with the 80% battery limit) in the bios. so it might be an acpi loop between UPower, ACPI, and the EC, that was causing my keyboard issue.

31

I used tsc=nowatchdog for a while, which has similar effect: forces the kernel to not check if tsc is “reliable”. I removed that because there could possibly be some bad side-effect from unreliable tsc timing of some kernel task, and I figure I probably don’t really need to optimize efficiency of my system by avoiding hpet for clocksource.

But on the other hand, it’s probably a good guess that tsc is not that bad and “reliable” enough for regular laptop use cases. On my most recent boot of linux 6.18.4 it was over 10 hours before:

[33295.874917] tsc: Marking TSC unstable due to clocksource watchdog

I think you’re on to something here … ACPI provides the system with methods to get battery info from the EC somehow, and I mentioned other evidence of the “cpu@4c” sensor going “bad” when there’s lots of polling of those sensors, and making it better by just blacklisting more “cros_ec” related modules, seemingly to reduce comms traffic to the EC. I’ll try the UPower config change, and look to see if battery level is still generally reliable, and if it helps with the cpu temp sensors reliability.

32

I’m still experiencing the old bug where my Framework Laptop sometimes doesn’t charge, even when it’s plugged in. Details at the already closed original topic Laptop sometimes not charging when first plugged in

33

Most users are protected when Daddy Microsoft blocks them from installing things. In our case, we probably don’t need it. I leave it on as part of my defense in depth strategy :wink:.