cpufreqd forces minfreq to 100%

[bugproxy]

== Comment: #0 - PAVAMAN SUBRAMANIYAM <email address hidden> - 2016-11-23 03:27:34 ==
---Problem Description---
cpufreq-set --freq option is not able to set the specific frequency value

Contact Information = <email address hidden>

---uname output---
Linux ltc-garri2 4.8.0-27-generic #29-Ubuntu SMP Thu Oct 20 21:01:16 UTC 2016 ppc64le ppc64le ppc64le GNU/Linux

Machine Type = P8

---Debugger---
A debugger is not configured

---Steps to Reproduce---
Install a P8 Open Power Hardware with Ubuntu 16.10 OS.
Then we are executing cpufreq-set which is a small tool which allows to modify cpufreq settings.

root@ltc-garri2:~# cpufreq-info -c 0
cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to <email address hidden>, please.
analyzing CPU 0:
  driver: powernv-cpufreq
  CPUs which run at the same hardware frequency: 0 1 2 3 4 5 6 7
  CPUs which need to have their frequency coordinated by software: 0 1 2 3 4 5 6 7
  maximum transition latency: 4294.55 ms.
  hardware limits: 2.06 GHz - 4.02 GHz
  available frequency steps: 4.02 GHz, 3.99 GHz, 3.96 GHz, 3.92 GHz, 3.89 GHz, 3.86 GHz, 3.82 GHz, 3.79 GHz, 3.76 GHz, 3.72 GHz, 3.69 GHz, 3.66 GHz, 3.62 GHz, 3.59 GHz, 3.56 GHz, 3.52 GHz, 3.49 GHz, 3.46 GHz, 3.42 GHz, 3.39 GHz, 3.36 GHz, 3.33 GHz, 3.29 GHz, 3.26 GHz, 3.23 GHz, 3.19 GHz, 3.16 GHz, 3.13 GHz, 3.09 GHz, 3.06 GHz, 3.03 GHz, 2.99 GHz, 2.96 GHz, 2.93 GHz, 2.89 GHz, 2.86 GHz, 2.83 GHz, 2.79 GHz, 2.76 GHz, 2.73 GHz, 2.69 GHz, 2.66 GHz, 2.63 GHz, 2.59 GHz, 2.56 GHz, 2.53 GHz, 2.49 GHz, 2.46 GHz, 2.43 GHz, 2.39 GHz, 2.36 GHz, 2.33 GHz, 2.29 GHz, 2.26 GHz, 2.23 GHz, 2.19 GHz, 2.16 GHz, 2.13 GHz, 2.09 GHz, 2.06 GHz
  available cpufreq governors: conservative, ondemand, userspace, powersave, performance
  current policy: frequency should be within 4.02 GHz and 4.02 GHz.
                  The governor "userspace" may decide which speed to use
                  within this range.
  current CPU frequency is 4.02 GHz (asserted by call to hardware).
  cpufreq stats: 4.02 GHz:100.00%, 3.99 GHz:0.00%, 3.96 GHz:0.00%, 3.92 GHz:0.00%, 3.89 GHz:0.00%, 3.86 GHz:0.00%, 3.82 GHz:0.00%, 3.79 GHz:0.00%, 3.76 GHz:0.00%, 3.72 GHz:0.00%, 3.69 GHz:0.00%, 3.66 GHz:0.00%, 3.62 GHz:0.00%, 3.59 GHz:0.00%, 3.56 GHz:0.00%, 3.52 GHz:0.00%, 3.49 GHz:0.00%, 3.46 GHz:0.00%, 3.42 GHz:0.00%, 3.39 GHz:0.00%, 3.36 GHz:0.00%, 3.33 GHz:0.00%, 3.29 GHz:0.00%, 3.26 GHz:0.00%, 3.23 GHz:0.00%, 3.19 GHz:0.00%, 3.16 GHz:0.00%, 3.13 GHz:0.00%, 3.09 GHz:0.00%, 3.06 GHz:0.00%, 3.03 GHz:0.00%, 2.99 GHz:0.00%, 2.96 GHz:0.00%, 2.93 GHz:0.00%, 2.89 GHz:0.00%, 2.86 GHz:0.00%, 2.83 GHz:0.00%, 2.79 GHz:0.00%, 2.76 GHz:0.00%, 2.73 GHz:0.00%, 2.69 GHz:0.00%, 2.66 GHz:0.00%, 2.63 GHz:0.00%, 2.59 GHz:0.00%, 2.56 GHz:0.00%, 2.53 GHz:0.00%, 2.49 GHz:0.00%, 2.46 GHz:0.00%, 2.43 GHz:0.00%, 2.39 GHz:0.00%, 2.36 GHz:0.00%, 2.33 GHz:0.00%, 2.29 GHz:0.00%, 2.26 GHz:0.00%, 2.23 GHz:0.00%, 2.19 GHz:0.00%, 2.16 GHz:0.00%, 2.13 GHz:0.00%, 2.09 GHz:0.00%, 2.06 GHz:0.00% (12)

Then try to set the specific frequency to be set for cpu0.

root@ltc-garri2:~# cpufreq-set -c 0 --freq 3.92GHz
root@ltc-garri2:~# echo $?
0

root@ltc-garri2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_nominal_freq
3258000
root@ltc-garri2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq
2061000
root@ltc-garri2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
4023000
root@ltc-garri2:~# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
4023000

As can be seen the new frequency value is not getting set.
The /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq value still shows 4023000 or 4.02GHz but we tried to set 3.92GHz.

Stack trace output:
 no

Oops output:
 no

Userspace tool common name: /usr/bin/cpufreq-set

Userspace rpm: cpufrequtils

The userspace tool has the following bit modes: 64-bit

System Dump Info:
  The system is not configured to capture a system dump.

Userspace tool obtained from project website: na

*Additional Instructions for <email address hidden>:
-Post a private note with access information to the machine that the bug is occuring on.
-Attach sysctl -a output output to the bug.
-Attach ltrace and strace of userspace application.

== Comment: #2 - SEETEENA THOUFEEK <email address hidden> - 2016-11-23 03:47:40 ==
Screening the issue.

== Comment: #11 - Akshay Adiga <email address hidden> - 2016-11-23 10:31:56 ==
Pavaman,

I figured out that this is not a cpufrequtils bug but this is because of way cpufreqd sets a profile.

1) It sets min, max and governor. No other tools is doing so. Hence if we try to change frequency policies with any tool, the scaling_min_freq still remains unchanged.
2) On installing cpufreqd, a init script /etc/init.d/cpufreqd is added , which will over-ride the default governor
set by kernel ( which is ondemand)

You right the scaling_min_freq is being written by init scripts /etc/init.d/cpufreqd , which loads the cpufreqd (daemon) based on the configuration file ( /etc/cpufreq.conf)

/etc/cpufreq.conf tells cpufreqd to set both min and max to 100%.

[Profile]
name=Performance High
minfreq=100%
maxfreq=100%
policy=performance
#exec_post=echo 8 > /proc/acpi/sony/brightness
[/Profile]

As such cpufreqd is totally out of sync with the developements in the community and still relies on the acpi provided sensors to make the decision ( These are mentioned in .conf under [Rules]) . But as we donot have any of the files which it looks for, it falls back to set the first profile mentioned in the cpufreqd.conf .

To fix this issue, we change the configuration to set minfreq=0% , profile will look like this :
[Profile]
name=Performance High
minfreq=0%
maxfreq=100%
policy=performance
#exec_post=echo 8 > /proc/acpi/sony/brightness
[/Profile]

== Comment: #15 - Akshay Adiga <email address hidden> - 2016-11-23 23:23:11 ==

[bugproxy (bugproxy)]

Default Comment by Bridge

[Manoj Iyer (manjo)]

This package is supported by the community, it would require a community effort to resolve this issue.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-09-12 19:01 EDT-------
16.10 reached EOL in July. Closing as WILL_NOT_FIX for 16.10.