lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 20 Nov 2019 21:42:12 +0100
From:   Tom Psyborg <pozega.tomislav@...il.com>
To:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [RFC] why do sensors break CPU scaling

Hi

Recently I've needed to set lowest CPU scaling profile, running ubuntu
16.04.06 I used standard approach - echoing powersave to
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor.
This did not work as the
/sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq kept returning
max scaling freq.

During testing of ubuntu 19.10 I've found that the above approach
actually does work, but as long as there are no xsensors (or just
sensors from cli) being run.
cpuinfo_cur_freq in this case was returning variable values +- 1% of
around 1.4GHz.
As soon as I issue sensors command cpuinfo_cur_freq jumps to 3.5GHz
for a fraction of second and returns back to 1.4GHz afterwards. If
running xsensors it keeps bouncing between 1.4 and 3.5GHz all the
time.

Rebooted back to 16.04.6 and was able to set lowest CPU scaling freq
as well, but issuing sensors command here once just breaks CPU scaling
that now remains at about 3.5GHz.
It can be set to lowest scaling freq again without rebooting but it
needs to change scaling_governor for all cores to something else and
then back to powersave.

Why is this happening, shouldn't sensors command just read temp/fan
values without writing to any of the CPU control registers?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ