throttled: Write to unrecognized MSR on Linux 5.9
I recently updated to kernel 5.9 and started seeing the kernel log this, seems to be caused by throttled:
[ 140.603433] msr: Write to unrecognized MSR 0x1a2 by python3
Please report to x86@kernel.org
[ 140.603516] msr: Write to unrecognized MSR 0x64b by python3
Please report to x86@kernel.org
The article here seems to suggest these logs are just for information purposes and there shouldn’t be any impact on userspace programs. Nevertheless, I wanted to open this issue for tracking this and maybe putting something in the README.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Reactions: 25
- Comments: 32 (7 by maintainers)
Commits related to this issue
- Add allow_writes=on to the MSR module parameters. Workaround for #206, #215 and #228 — committed to erpalma/throttled by erpalma 4 years ago
You have to add this to grub:
GRUB_CMDLINE_LINUX=“msr.allow_writes=on”
and update grub 😉
Cool, I’d be glad to.
So how about you send a mail to x86-at-kernel.org (replace the “-at-” with you know what 😃) with what exactly you’d like to read out/program from/to which MSRs and I’ll CC the relevant people and we’ll start the ball rolling. From initial staring, some of the info you need we export already - it’ll just need to be extended/designed properly so yours and other tools can use it too.
Thx.
How about, instead of bypassing something which we added there for a good reason, you guys work with us?
For example, the 0x1a2 MSR is accessible to userspace through the drivers/thermal/intel/int340x_thermal/processor_thermal_device.c driver. On machines which have that hw, there should be a sysfs file called “tcc_offset_degree_celsius” which gives you the TCC activation offset. We’re open to suggestions how to extend that interface so that your tool can read it from sysfs instead of poking at MSRs.
The other MSR above is MSR_CONFIG_TDP_CONTROL and the kernel uses it in a bunch of places. It looks like throttled wants to set cTDP so exposing that functionality in sysfs shouldn’t be a big deal AFAICT.
So let’s do this right please and stop poking at the naked MSRs because it is a very bad idea.
Thx.
This tool started just as a simple way “to fix my own pc”. I agree with you that the right decision would be to use specific sysfs instead of raw MSRs. I would be very glad to upgrade this tool if you are going to help us by submitting the required patches for the kernel.
Yeah, that’s me poking at people to get this thing moving. Thus it will be important if you give your requirements about what you want to access through the MSRs so that you can use that interface in your tool too.
Thx.
I do not touch the boot switches, I change the MSR module parameters at runtime. The effect is the same.
The workaround is not working for me.
I added
msr.allow_writes=onto my boot string and rebuilt Grub (I did both those things using the Grub Customizer program) I rebooted. My log is still being flooded with the message at issue.Mint 20 x64 Cinnamon, kernel 5.9.1-050901-generic. My full kernel/boot string:
acpi=force cpuidle.governor=teo i915.enable_fbc=1 i915.fastboot=1 pcie_aspm=force mitigations=off psmouse.synaptics_intertouch=1 quiet reboot=w splash msr.allow_writes=on. Computer: X1CG6.I will try with the 5.9.0 kernel. EDIT: on the 5.9.0 kernel, as against 5.9.1, the workaround does stop the log flood.
Adding msr.allow_writes=on to the kernel cmdline definitely works for now (tested on 5.9.0). However, writing to MSRs will probably become impossible in the future.
Backporting the MSR-driver to have the current behaviour on newer kernels OR a reimplementation of throttled as a kernel-module might be the only way in the midterm.
Thoughts?