Which commands differ? If you mean wrmsr, it’s a separate installable module with its own syntax independent of the OS.
I believe your problem is that you have Secure Boot enabled (which certainly isn’t secure on a Stinkpad so you might as well disable it). For best results, replace it with a Librem 
3 Likes
dnf search wrmsr
No matches found.
Yes! you got it! Thanks. I disabled secure boot and it worked immediately. I did not think about secure boot…
You’re welcome, but I didn’t think of it, either. Searching for error messages can go a long way toward making one look like an expert.
1 Like
Huh? Did you:
sudo apt install msr-tools
sudo modprobe msr
in Qubes? (Or the equivalent if apt isn’t available?)
1 Like
Thank you, I managed to install msr on Qubes like this:
sudo qubes-dom0-update wrmsr
Then I do the following:
sudo modprobe msr
sudo rdmsr -p0 0x1A0 -f 38:38
0
sudo rdmsr -p0 0x1A0
811809
sudo wrmsr -a 0x1A0 0x4000811809
sudo rdmsr -p0 0x1A0 -f 38:38
0
Somehow the bit does not change and nothing happens… This is L15v3. Any help is appreciated.
Is this because you’re not in dom0, so this MSR is being virtualized, and therefore doesn’t change because it can’t have physical ramifications?
Actually I am in dom0…
Out of curiosity tried it in a Fedora VM and it behaves in the same way, except
sudo rdmsr -p0 0x1A0
851889
It seems this is the problem with the Qubes:
1 Like
Ok, I successfully reduced the CPU frequency with
sudo xenpm set-scaling-maxfreq 0 1600
sudo xenpm set-scaling-maxfreq 2 1600
and the machine runs quietly even at a high load now.
There is also
sudo xenpm disable-turbo-mode 0
sudo xenpm disable-turbo-mode 2
which helps, too!
3 Likes
Thank you everybody for this thread! That obnoxius fan is genuinely distracting everytime you try to do any work that requires concentration.
1 Like
OMG, you just solved one of my biggest problems with my Librem 13v4. I just disabled Turbo Boost and the fan never turned up again. Thank you!!
Edit: and for whoever might read this. Enabling Gnome extensions is a bit tricky these days - I installed Chromium and used the add-on. Flatpak-Firefox doesn’t work.
1 Like
Pro tip for those of us doing lots of video conferencing these days: minimize the video window as much as possible. That will reduce CPU utilization, lower the need for fan spinup, and improve latency for everything else. And don’t forget your lovely hardware kill switch, so you can disable camera and mic before you minimize, just in case you forget you’re being recorded! (Just beware that it only affects builtin devices, not those out on USB.)
While I’m on the topic, I’ve done some execution time analysis in some intensive processes that I often run. Turbo Boost made a trivial, if detectable, difference. I guess that’s because those tasks are memory-bound. But then, most expensive tasks are, these days. This is yet another motivating reason for the next Librem spin to aim for bottom tier MHz and spend the difference on components that do more to support performance without overtaxing battery life. Even ECC would add way more value for the dollar than top SKU vs. bottom SKU within a given model.
My output reads this:
$ sudo rdmsr -p0 0x1A0
811809
$ sudo rdmsr -p0 0x1A0 -f 38:38
0
This is running Qubes. How should I change it?
Did you try searching Qubes in this topic? See my replies above.
Fan is still running at high speeds on R4.1. Maybe it’s slightly better though. I also get the same results as you when following this comment about reading and writing to msr.
Did anyone try the HWP patch mentioned in the Qubes scaling bug report on github? Sounds like it helps a lot, but unsure how to apply it. I see options for both 4.0.4 (which i am running) and 4.1RC.
1 Like
I have started to use the GNOME cpupower extension and so far experienced two “freeze ups” of my Librem 13v4 CPU at 0.4GHz: It just stays at that frequency (and fan runs continuously) even though I manipulate settings via cpupower/pstate. Just wondering if anybody else had a similar experience?
I did some browser tests and made the amazing discovery that even a tiny animated area smaller than 0.1% of the screen is enough to get the fan pulsing. Locking the screen does little to thwart this (because the OS still has to track screen changes in preparation for unlock), but minimizing the offending browser window without locking does.
I suspect this is because animations (even just UI buttons which oscillate in brightness) cause the CPU to go through periodic UI event processing and associated OS calls, ultimately resulting in fan activation after however many animation frame cycles:
- Go to sleep (higher C state).
- Wake up from a high C state to full throttle.
- Navigate atrocious browser event handling stack.
- Do a compatively trivial amount of animation work.
- Goto 1.
Disabling Turbo had no effect on this low-level but frequent activation.
I wonder how much CO2 this sort of nonsense is dissipating. The actual frame render may be trivial, but UI event processing is generally not.