OpenMandriva Lx version:
OM Lx 3 on 2 different partitions one is fully updated with standard repos and the other is fully updated with testing repos. Both show high temps. As best I can tell this has occurred for 2 weeks of less.
Desktop environment (KDE, LXQT…):
KDE/Plasma5
Description of the issue (screenshots if relevant):
Screenshot shows reading of sensors with Konsole, Quassel, and Firefox open and not much else going on. This is more than 20-25 degrees C higher than readings I used to get on OM Lx 3 say a month or more ago. To be fair the readings keep going up and down and this is the high end of what I’ve seen. The lowest temp readings are still up 5-10 degrees C compared to what I used to see in Lx 3 and what I still see in other Linux partitions (openSUSE, Manjaro).
Relevant informations (hardware involved, software version, logs or output…):
This is on a hardware system on a multi-boot computer. I will post a screen shot from another partition on same computer to demonstrate difference.
Does anyone know of any changes in OM Lx 3 recently that would account for higher CPU temperature readings?
Are any other users regularly monitoring ‘sensors’ (also ‘hddtemp’) and if so has anyone else seen this temperature increase in Lx 3?
FWIW I don’t see elevated readings with ‘hddtemp’. Another point is that when I see higher CPU temps my computer fans get louder as they run faster. Also if it were something like bad sensors I would see the same readings in other Linux distros but I don’t see that, other Linux distros show consistently cooler readings.
I have tried with different 4.15.x kernel versions and that does not seem to be the issue unless issue predates kernel 4.15.x. I doubt this or I would have seen the problem sooner.
One obvious question would be if there are any runaway processes using a lot of CPU or 100% of a core or something like that. No these readings are observed with CPU usages in 1-5% range.
Edit: Also no excess memory usage or network or anything else I’ve thought to check so far.
Thanks for the input @jimmyc. If you are using Lx 3 and fully (or close enough to it) updated and running at 32 C then my problem may partly be related to hardware like a Haswell processor (Intel i5 4590). But it can’t be totally hardware or my system would not run cooler in Manjaro or openSUSE partitions. Or so I’m thinking.
Progress on this. With the help of Gabriel Craciunescu on IRC (#openmandriva-cooker) we found that the way OM Lx 3 is configured cpupower was not working. To check your own:
# systemctl status cpupower
and if it isn’t running try:
# systemctl start cpupower
# systemctl status cpupower
so we (actually Gabriel) created 4 files that included some custom settings and also allow CPU power management to be controlled by cpupower and other stuff to be controlled by tuned.service. In the past in OM Lx 3 tuned.service controlled all of this. What we found is that with OM’s way if user runs:
# cpupower frequency-info
then the “current CPU frequency” would always be at or very near the max for the CPU. The custom settings allow for the “current CPU frequency” to be controlled by cpupower resulting in much, much lower “current CPU frequency” which translated to a cooler running CPU.
This corrected my elevated CPU temps at idle or with desktop just sitting around.
Postedit: Note: This issue has been with me for at least 6 weeks. I’m by no means and expert with Tuned but I did play (a lot) with Tuned settings and nothing in that regard ever had any affect on my CPU temps. It is not like I did not try anything else before coming to this conclusion for this issue.
Thanks @jimmyc and @mandian for you input. Thanks Gabriel Craciunescu for getting me to this point with this issue. Now I can “hang out” in OpenMandriva Lx 3 again instead of my openSUSE or Manjaro partitions.
Here you may find some useful info about CPU frequency scaling also referred to Intel processors. I remember for some kind of processors the only usable choice was to use performances governator, but this highly depends on the specific processors are you using.
– L’unité (unit) cpupower.service a échoué, avec le résultat RESULT.
juin 11 20:35:04 localhost.localdomain tuned[7677]: Exception in thread Thread-1:
juin 11 20:35:04 localhost.localdomain tuned[7677]: Traceback (most recent call last):
juin 11 20:35:04 localhost.localdomain tuned[7677]: File “/usr/lib64/python3.4/threading.py”, line 911, in _bootstrap_inner
juin 11 20:35:04 localhost.localdomain tuned[7677]: self.run()
juin 11 20:35:04 localhost.localdomain tuned[7677]: File “/usr/lib64/python3.4/threading.py”, line 859, in run
juin 11 20:35:04 localhost.localdomain tuned[7677]: self._target(*self._args, **self._kwargs)
juin 11 20:35:04 localhost.localdomain tuned[7677]: File “/usr/lib/python3.4/site-packages/tuned/daemon/daemon.py”, line 175, in _thread_code
juin 11 20:35:04 localhost.localdomain tuned[7677]: if self._full_rollback_required():
juin 11 20:35:04 localhost.localdomain tuned[7677]: File “/usr/lib/python3.4/site-packages/tuned/daemon/daemon.py”, line 126, in _full_rollback_required
juin 11 20:35:04 localhost.localdomain tuned[7677]: return re.search(r"\b(shutdown|reboot|halt|poweroff).target.*start", out) is None
juin 11 20:35:04 localhost.localdomain tuned[7677]: File “/usr/lib64/python3.4/re.py”, line 170, in search
juin 11 20:35:04 localhost.localdomain tuned[7677]: return _compile(pattern, flags).search(string)
juin 11 20:35:04 localhost.localdomain tuned[7677]: TypeError: can’t use a string pattern on a bytes-like object
juin 11 20:35:04 localhost.localdomain systemd[1]: Stopped Dynamic System Tuning Daemon.
I wonder if this isn’t related to the last cpupower update:
cpupower-4.16.13-1-omv2015.0.x86_64 Thu Jun 7 13:41:58 2018
OK, I’ve checked my own logs in freshly installed system with no testing packages (only packages from release and updates repos). System is fully updated. There have been no changes or customizations to system package. No changes to cpupower or tuned. And I have that exact output as well. It occurs as the system is shutting down so I don’t believe this indicates that tuned isn’t working. As far as I know tuned is working on my system.
This show tuned working on the system mentioned in my last post:
$ systemctl status tuned
● tuned.service - Dynamic System Tuning Daemon
Loaded: loaded (/lib/systemd/system/tuned.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2018-06-13 11:07:10 CDT; 4h 52min ago
Docs: man:tuned(8)
man:tuned.conf(5)
man:tuned-adm(8)
Main PID: 3623 (tuned)
Tasks: 5 (limit: 4915)
Memory: 19.0M
CGroup: /system.slice/tuned.service
└─3623 /usr/bin/python -Es /usr/sbin/tuned -l -P
Jun 13 11:07:07 ben79-pc systemd[1]: Starting Dynamic System Tuning Daemon...
Jun 13 11:07:10 ben79-pc systemd[1]: Started Dynamic System Tuning Daemon.
Post edit: And:
# tuned-adm verify
Verfication succeeded, current system settings match the preset profile.
See tuned log file ('/var/log/tuned/tuned.log') for details.
# tuned-adm active
Current active profile: balanced
Also tuned has it’s own logs in ‘/var/log/tuned/tuned.log’.
The only thing I see amiss with the package in updates repo is the command:
# tuned-adm recommend
DBus call to Tuned daemon failed
Traceback (most recent call last):
File "/usr/sbin/tuned-adm", line 94, in <module>
result = admin.action(action_name, **options)
File "/usr/lib/python3.4/site-packages/tuned/admin/admin.py", line 81, in action
res = action(*args, **kwargs)
File "/usr/lib/python3.4/site-packages/tuned/admin/admin.py", line 285, in _action_recommend_profile
print(self._cmd.recommend_profile())
File "/usr/lib/python3.4/site-packages/tuned/utils/commands.py", line 435, in recommend_profile
matching = self.process_recommend_file(path)
File "/usr/lib/python3.4/site-packages/tuned/utils/commands.py", line 391, in process_recommend_file
if not re.match(value, self.execute("virt-what")[1], re.S):
File "/usr/lib64/python3.4/re.py", line 160, in match
return _compile(pattern, flags).match(string)
TypeError: can't use a string pattern on a bytes-like object
does not work. It is supposed to work, I think it is anyway. I wish it did.
Maybe this from ‘/var/log/tuned/tuned.log’ has something to do with my elevated CPU temps with desktop at rest:
...
2018-06-12 20:28:31,755 WARNING tuned.plugins.plugin_cpu: unable to run x86_energy_perf_policy tool, ignoring CPU energy performance bias, is the tool installed?
2018-06-12 20:28:31,755 INFO tuned.plugins.plugin_cpu: intel_pstate detected
...
2018-06-12 20:28:31,762 INFO tuned.plugins.plugin_cpu: ignoring governor 'conservative' on cpu 'cpu0', it is not supported
2018-06-12 20:28:31,763 INFO tuned.plugins.plugin_cpu: ignoring governor 'conservative' on cpu 'cpu1', it is not supported
2018-06-12 20:28:31,763 INFO tuned.plugins.plugin_cpu: ignoring governor 'conservative' on cpu 'cpu3', it is not supported
2018-06-12 20:28:31,763 INFO tuned.plugins.plugin_cpu: ignoring governor 'conservative' on cpu 'cpu2', it is not supported
2018-06-12 20:28:31,763 INFO tuned.plugins.plugin_cpu: setting new cpu latency 100
2018-06-12 20:28:31,764 ERROR tuned.utils.commands: Error when reading file '/sys/class/drm/card0/device/power_method': '[Errno 2] No such file or directory: '/sys/class/drm/card0/device/power_method''
...
2018-06-12 20:39:41,842 INFO tuned.plugins.plugin_cpu: setting new cpu latency 1000
2018-06-12 20:40:01,844 INFO tuned.plugins.plugin_cpu: setting new cpu latency 100
2018-06-12 20:41:11,850 INFO tuned.plugins.plugin_cpu: setting new cpu latency 1000
2018-06-12 20:41:21,852 INFO tuned.plugins.plugin_cpu: setting new cpu latency 100
...
Post edit: And remember that my initial problem is CPU temps but it has been demonstrated that the likely cause is that the CPU frequency stays at or near max all the time. As shown by ‘cpupower frequency-info’ in this line:
...
hardware limits: 800 MHz - 3.30 GHz
...
current CPU frequency: 3.25 GHz (asserted by call to kernel)
...
