Bug 891134 - CPU frequency is no longer scaling and is fixed at minimum value after suspend+resume
Summary: CPU frequency is no longer scaling and is fixed at minimum value after suspen...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 17
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-02 00:08 UTC by Jonathan Underwood
Modified: 2013-01-04 17:52 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-01-04 17:52:57 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
dmesg output for this machine (116.24 KB, application/octet-stream)
2013-01-02 00:08 UTC, Jonathan Underwood
no flags Details

Description Jonathan Underwood 2013-01-02 00:08:34 UTC
Created attachment 671183 [details]
dmesg output for this machine

Description of problem:
My laptop CPU is no longer having its CPU frequency scaled by the ondemand govern.

cpupower has the following output:

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


Notice "frequency should be within 1000 MHz and 1000 MHz". This is while running on AC power, not battery. The cpupower service is running.

This seems to have been a problem since F16:
http://forums.fedoraforum.org/showthread.php?t=272109


Version-Release number of selected component (if applicable):
$ uname -ar
Linux m1210.jgu 3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Comment 1 Jonathan Underwood 2013-01-02 01:30:25 UTC
Aha. Interesting. So, I upgraded to kernel-3.6.11-1.fc17.x86_64 (updates-testing).

On reboot, I find that CPU scaling is working correctly initially, but then breaks again after a suspend+resume cycle.

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


Following a suspend and resume:
#  cpupower frequency-info 
analyzing CPU 0:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 0
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 2.00 GHz
  available frequency steps: 2.00 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 1000 MHz and 1000 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz (asserted by call to hardware).
  boost state support:
    Supported: no
    Active: no

Comment 2 Jonathan Underwood 2013-01-04 17:52:57 UTC
Further investigation found the root of the problem. Inspecting /sys/devices/system/cpu/cpu0/cpufreq/bios_limit showed that contained a value of 1000000. So the bios was insisting the CPU speed was stuck at the minimum. Further investigation showed that, although the laptop was on AC power, the battery was no longer holding charge and at 0%. This is presumably why the bios was clocking the CPU down - removing the battery resulted in bios_limit resetting to 2000000 and CPU scaling working again. So, it seems the bios was being stupid. I think therefore this is not a kernel bug, so I'll close it.


Note You need to log in before you can comment on or make changes to this bug.