Bug 488974 – [PATCH PROPOSED] sys-power/cpufrequtils-008-r4 - /usr/libexec/cpufrequtils-change.sh points to /sys/devices/system/cpu/cpufreq which no longer exists with hardened-sources-3.11.2

• Status: RESOLVED WONTFIX
• Product: Gentoo Linux

[Description razamatan 2013-10-22 07:43:30 UTC]

/usr/libexec/cpufrequtils-change.sh tests for /sys/devices/system/cpu/cpufreq which doesn't exist under hardened-sources-3.11.2 .  i've compiled in the necessary kernel modules, and the cpu specific paths for cpufreq still exists (along with the right files in them):

$ ls -d /sys/devices/system/cpu/cpu[0-9]*/cpufreq | cat
/sys/devices/system/cpu/cpu0/cpufreq
/sys/devices/system/cpu/cpu1/cpufreq
/sys/devices/system/cpu/cpu2/cpufreq
/sys/devices/system/cpu/cpu3/cpufreq
/sys/devices/system/cpu/cpu4/cpufreq
/sys/devices/system/cpu/cpu5/cpufreq
/sys/devices/system/cpu/cpu6/cpufreq
/sys/devices/system/cpu/cpu7/cpufreq

here's cpufreq-info output:

$ sudo cpufreq-info 
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to [e-mail], please.
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 0.97 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.80 GHz (asserted by call to hardware).
analyzing CPU 1:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 0.97 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.73 GHz (asserted by call to hardware).
analyzing CPU 2:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 2
  CPUs which need to have their frequency coordinated by software: 2
  maximum transition latency: 0.97 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.60 GHz (asserted by call to hardware).
analyzing CPU 3:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 3
  CPUs which need to have their frequency coordinated by software: 3
  maximum transition latency: 0.97 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.35 GHz (asserted by call to hardware).
analyzing CPU 4:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 4
  CPUs which need to have their frequency coordinated by software: 4
  maximum transition latency: 0.97 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.04 GHz (asserted by call to hardware).
analyzing CPU 5:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 5
  CPUs which need to have their frequency coordinated by software: 5
  maximum transition latency: 0.97 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.77 GHz (asserted by call to hardware).
analyzing CPU 6:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 6
  CPUs which need to have their frequency coordinated by software: 6
  maximum transition latency: 0.97 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 1.70 GHz (asserted by call to hardware).
analyzing CPU 7:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 7
  CPUs which need to have their frequency coordinated by software: 7
  maximum transition latency: 0.97 ms.
  hardware limits: 1.60 GHz - 3.90 GHz
  available cpufreq governors: performance, powersave
  current policy: frequency should be within 1.60 GHz and 3.90 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency is 2.21 GHz (asserted by call to hardware).


the cpufrequtils-change.sh will likely need to be updated to reflect just the cpu specific paths instead of depending on the toplevel cpu/cpufreq path.

Reproducible: Always

Steps to Reproduce:
1. compile hardened sources w/ the right cpu freq stuff (specifically, i'm using the intel_pstate driver)
2. emerge cpufrequtils stable
3. /etc/init.d/cpufrequtils start
Actual Results:  
 * Running cpufreq-set --governor powersave -- ...
/usr/libexec/cpufrequtils-change.sh: line 26: cd: /sys/devices/system/cpu/cpufreq: No such file or directory                        [ !! ]
 * ERROR: cpufrequtils failed to start


Expected Results:  
cpufreq-set success

[Comment 1 razamatan 2013-11-02 09:57:06 UTC]

got tired of waiting.  here's a patch that fixes this trivial bug.  if there's no SYSFS_EXTRA settings set, the inner for loop does nothing, so this block can completely be skipped.  so test the extra governor options instead of arg length.

============= cut
--- /usr/portage/sys-power/cpufrequtils/files/cpufrequtils-change.sh    2013-05-09 13:31:31.000000000 -0700
+++ cpufrequtils-change.sh      2013-11-02 02:35:53.380463563 -0700
@@ -21,7 +21,7 @@
        : $(( ret += $? ))
 done
 
-if [ $# -gt 0 ] ; then
+if [ ! -z "${gov_opts}" ] ; then
        c=1
        if cd /sys/devices/system/cpu/cpufreq ; then
                for o in ${gov_opts}; do
============= cut

[Comment 2 gentoolinux 2014-04-24 15:15:53 UTC]

I can confirm the issue. I had the same problem after switching from kernel 3.10.25-gentoo to 3.12.13-gentoo:

# /etc/init.d/cpufrequtils restart
 * Running cpufreq-set --governor performance ...
/usr/libexec/cpufrequtils-change.sh: line 26: cd: /sys/devices/system/cpu/cpufreq: No such file or directory                                                                                                 [ !! ]
 * ERROR: cpufrequtils failed to stop

# ls -l /sys/devices/system/cpu/
total 0
drwxr-xr-x 6 root root    0 24. Apr 2014  cpu0
drwxr-xr-x 5 root root    0 24. Apr 2014  cpu1
drwxr-xr-x 2 root root    0 24. Apr 16:53 cpuidle
-r--r--r-- 1 root root 4096 24. Apr 16:53 kernel_max
-r--r--r-- 1 root root 4096 24. Apr 16:53 modalias
-r--r--r-- 1 root root 4096 24. Apr 16:53 offline
-r--r--r-- 1 root root 4096 24. Apr 16:52 online
-r--r--r-- 1 root root 4096 24. Apr 16:53 possible
drwxr-xr-x 2 root root    0 24. Apr 16:53 power
-r--r--r-- 1 root root 4096 24. Apr 16:53 present
--w------- 1 root root 4096 24. Apr 16:53 probe
--w------- 1 root root 4096 24. Apr 16:53 release
-rw-r--r-- 1 root root 4096 24. Apr 2014  uevent

# ls -d /sys/devices/system/cpu/cpu[0-9]*/cpufreq | cat
/sys/devices/system/cpu/cpu0/cpufreq
/sys/devices/system/cpu/cpu1/cpufreq

The proposed patch (thanks razamatan!) fixes the bug for me and CPU frequency scaling is working again.

[Comment 3 mfld.fr 2014-11-16 11:07:00 UTC]

Same problem with:
- gentoo-sources 3.16.5
- cpufrequtils 008-r4

Current file /usr/libexec/cpufrequtils-change.sh points to:
  /sys/devices/system/cpu/cpufreq

But actual paths depends on the number of processors as reported previously.
  /sys/devices/system/cpu/cpu{0..N}/cpufreq

[Comment 4 Pacho Ramos 2015-02-03 14:52:05 UTC]

removed

[Comment 5 mfld.fr 2015-02-04 19:47:18 UTC]

This closure comment is quite straight... maybe we could add some more information here for the next visitors:

# emerge -p cpufrequtils

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   #] sys-power/cpufrequtils-008-r4 

The following mask changes are necessary to proceed:
 (see "package.unmask" in the portage(5) man page for more details)
# required by cpufrequtils (argument)
# /usr/portage/profiles/package.mask:
# Pacho Ramos <[e-mail]> (01 Dec 2014)
# Upstream dead for a long time, use sys-power/cpupower
# instead. Removal in a month.
=sys-power/cpufrequtils-008-r4

NOTE: The --autounmask-keep-masks option will prevent emerge
      from creating package.unmask or ** keyword changes.