On 15.01.2025 11:18, Norman Feske wrote:
this reminds me of a situation I sporadically encountered on my Gen12 Framework laptop. Once heavily stressing the system by a large compile in "high-performance" mode, some kind of overheat protection of the firmware kicks in and forcibly throttles all cores to 400 Mhz.
Interestingly, the forced throttling is retained long after all temperatures have cooled down to less than 50 degrees. Usually, the situation recovers after 1/4 hour. In one case, however, the situation wouldn't even recover after reboot, even on the day after. Only detaching and re-attaching the battery (can be done in the BIOS menu) fixed it. It goes without saying that I keep using the "balanced" mode since then.
The effects of the firmware can be nicely observed using Alex' MSR GUI tool. I leave it running at all times.
I tried to run it but failed (used alex-ab/pkg/msr_gui/2024-10-30).
Initially it complained about menu_view expected to get more ram and caps than limits for runtime - although I don't know if it is required, I have extended limits in runtime element to silence them.
It has also reported:
[runtime -> msr_gui -> msr] ^[[31mError: - CPU or used kernel misses MSR access support^[[0m [runtime -> msr_gui -> msr] ^[[31mError: - and/or missing 'managing_system' configuration^[[0m
For this I have tried to add `managing_system="yes"` to runtime element, but it did not change anything. I'm not sure if it is about MSR or managing_system (I have Lenovo T460p). It would be great if you could suggest something to fix it or check.
I also have a copy of /report/log from that time, but I don't see anything suspicious there. By the way it would be useful if there was some kind of timestamp with log (it doesn't have to be a real time). Trying to correlate information from log with the performed actions is hard if you do not have any information about "age" of each log.
Noted [1].
Thank you very much.
Tomasz Gajewski