Bug 18925

Summary: cpupower fails to change frequencies and governor
Product: Mageia Reporter: Helge Hielscher <hhielscher>
Component: RPM PackagesAssignee: Kernel and Drivers maintainers <kernel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: release_blocker CC: eatdirt, ottoleipala1
Version: CauldronKeywords: UPSTREAM
Target Milestone: Mageia 6   
Hardware: All   
OS: Linux   
URL: https://bugzilla.kernel.org/show_bug.cgi?id=135391
Whiteboard:
Source RPM: kernel-4.7.0-0.rc6.3.mga6.src.rpm CVE:
Status comment: Might be fixed already upstream in 4.8

Description Helge Hielscher 2016-07-11 21:07:34 CEST
Description of problem: since about a week I can no longer change frequencies and cpu governor with cpupower.

Version-Release number of selected component (if applicable): 4.7.0-0.rc6.3.mga6.src.rpm

How reproducible: always, tried it on kernel 4.6.2-desktop-2.mga6 and the same results

BEFORE

# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 4.0 us
  hardware limits: 800 MHz - 2.70 GHz
  available frequency steps:  2.70 GHz, 2.00 GHz, 1.40 GHz, 800 MHz
  available cpufreq governors: ondemand conservative powersave userspace performance
  current policy: frequency should be within 800 MHz and 2.70 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: Unable to call hardware
  current CPU frequency: 800 MHz (asserted by call to kernel)
  boost state support:
    Supported: yes
    Active: yes

RUN CPUPOWER
# cpupower frequency-set -g ondemand --min 800000 --max 800000

RESULT
# cpupower frequency-info
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 4.0 us
  hardware limits: 800 MHz - 2.70 GHz
  available frequency steps:  2.70 GHz, 2.00 GHz, 1.40 GHz, 800 MHz
  available cpufreq governors: ondemand conservative powersave userspace performance
  current policy: frequency should be within 800 MHz and 2.70 GHz.
                  The governor "powersave" may decide which speed to use
                  within this range.
  current CPU frequency: 800 MHz (asserted by call to hardware)
  boost state support:
    Supported: yes
    Active: no
    Boost States: 1
    Total States: 5
    Pstate-Pb0: 3200MHz (boost state)
    Pstate-P0:  2700MHz
    Pstate-P1:  2000MHz
    Pstate-P2:  1400MHz
    Pstate-P3:  800MHz
Thierry Vignaud 2016-07-11 23:38:36 CEST

Assignee: bugsquad => tmb

Comment 1 Helge Hielscher 2016-07-17 21:15:08 CEST
This bug has also been reported upstream:
https://bugzilla.kernel.org/show_bug.cgi?id=135391
Comment 2 Chris Denice 2016-08-02 18:43:59 CEST
Confirmed, things changed, at least with intel driver, such as the path:

ls /sys/devices/system/cpu/cpufreq/
policy0/   policy11/  policy14/  policy17/  policy2/   policy22/  policy4/  policy7/
policy1/   policy12/  policy15/  policy18/  policy20/  policy23/  policy5/  policy8/
policy10/  policy13/  policy16/  policy19/  policy21/  policy3/   policy6/  policy9

ls /sys/devices/system/cpu/cpufreq/policy0/
affected_cpus     cpuinfo_transition_latency   scaling_driver    scaling_setspeed
cpuinfo_cur_freq  related_cpus                 scaling_governor
cpuinfo_max_freq  scaling_available_governors  scaling_max_freq
cpuinfo_min_freq  scaling_cur_freq             scaling_min_freq


such that the scaling_governor entries need to be modified for eatch cpus under "policyXXX".

CC: (none) => eatdirt

Comment 3 Marja Van Waes 2016-08-26 11:42:31 CEST
Mass-reassigning all bugs with "kernel" in the Source RPM field that are assigned to tmb, to the kernel packagers group, because tmb is currently MIA.

Assignee: tmb => kernel

Comment 4 Chris Denice 2016-09-22 19:49:16 CEST
Swtiched to release blocker, that's a no-go for performance computing server. We cannot switch to performance anymore.

Priority: Normal => release_blocker
Target Milestone: --- => Mageia 6

Comment 5 Rémi Verschelde 2016-10-17 14:08:25 CEST
Does it still happen with cpupower 4.8.2? I've seen Manjaro and Arch Linux reports that upstream planned to fix it by 4.8. (Can't check the upstream bko report right now to check sadly, bad proxy config :/).
Rémi Verschelde 2016-10-17 14:08:47 CEST

Keywords: (none) => UPSTREAM
Status comment: (none) => Might be fixed already upstream in 4.8
URL: (none) => https://bugzilla.kernel.org/show_bug.cgi?id=135391

Comment 6 Chris Denice 2016-10-25 15:37:19 CEST
Sadly, nothing has changed, they just don't care, even in spite of my comment upstream to urge them pushing one of their fix...
cpupower-4.8.3 is just useless :-/
Comment 7 Otto Leipälä 2016-10-31 16:01:16 CET
This is not first time from kernel devs they don't even answer to bugs open in their bugzilla,sadly because it's key part of whole linux.

CC: (none) => ozkyster

Comment 8 Chris Denice 2016-11-02 09:44:32 CET
Ok, our very kernel team has pushed a fixed on 4.8.6, and it works for me know.
Thank you guys!

I am closing, reopen if needed!
Cheers,
Chris.

Status: NEW => RESOLVED
Resolution: (none) => FIXED