Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 611885 - cpuspeed won't step up frequency with 2.6.32 kernels
cpuspeed won't step up frequency with 2.6.32 kernels
Status: CLOSED DUPLICATE of bug 618149
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
12
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-06 15:02 EDT by krlynch
Modified: 2010-08-06 16:19 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-08-06 16:19:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description krlynch 2010-07-06 15:02:36 EDT
Description of problem:

On my Lenovo T60 thinkpad with Core2 Duo, the 2.6.32 kernel version of cpuspeed is unable to switch the frequency from the lowest frequency step.  This worked correctly on the 2.6.31 kernels.  I only use stock fedora kernels.

How reproducible:

Always

Steps to Reproduce:
1. Boot a 2.6.32 kernenl
2. Launch a few long-running, compute bound processes.
  
Actual results:

The processor stays at the lowest frequency, despite pinning both cores at 100% utilization.  I noticed this first in the Gnome applet, but can confirm it with the output in /sys.

Expected results:

The processor frequency steps up when the processor is under load.  This works correctly in the F12 2.6.31 kernels.

Additional info:

This happens whether or not the machine is plugged in to AC power or not.  I have not modified cpuspeed policy files.

cpufreq-info output with a 2.6.31 kernel:
i-m-so-tired<~>% cpufreq-info
cpufrequtils 007: cpufreq-info (C) Dominik Brodowski 2004-2009
Report errors and bugs to cpufreq@vger.kernel.org, please.
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.17 GHz
  available frequency steps: 2.17 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 1000 MHz and 2.17 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz.
analyzing CPU 1:
  driver: acpi-cpufreq
  CPUs which run at the same hardware frequency: 0 1
  CPUs which need to have their frequency coordinated by software: 1
  maximum transition latency: 10.0 us.
  hardware limits: 1000 MHz - 2.17 GHz
  available frequency steps: 2.17 GHz, 1.67 GHz, 1.33 GHz, 1000 MHz
  available cpufreq governors: ondemand, userspace, performance
  current policy: frequency should be within 1000 MHz and 2.17 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1000 MHz.


In 2.6.32, the output is slightly different, in that the current policy section reads:
  current policy: frequency should be within 1000 MHz and 1000 MHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
I haven't modified the policy.
Comment 1 Chuck Ebbert 2010-08-03 19:05:53 EDT
Is this another instance of bug 618149 ?
Comment 2 krlynch 2010-08-05 22:02:54 EDT
Yes, it probably is.  When I boot with the instructions in bug 618149, the output of cpufreq-info matches the 2.6.31 kernels (at least the frequencies section).  Things don't quite seem to work entirely correctly, but if I can figure out what's going on, I'll submit a new bug report.
Comment 3 Chuck Ebbert 2010-08-06 16:19:25 EDT

*** This bug has been marked as a duplicate of bug 618149 ***

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