Bug 618149 - cpufreq sometimes stuck at lowest frequency
cpufreq sometimes stuck at lowest frequency
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 611885 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-26 05:24 EDT by Pierre Ossman
Modified: 2010-08-06 16:20 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-07-27 17:03:43 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)


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 16362 None None None Never

  None (edit)
Description Pierre Ossman 2010-07-26 05:24:46 EDT
This is a  problem that's been around for some time on this machine. Sometimes the kernel decides that it won't scale the cpu beyond the lowest frequency. It doesn't matter if you change governor, or try to force the frequency up by reconfiguring the ondemand governor.

Sometimes the machine leaves and enter this weird state by itself intermittently. Usually you need to yank the power cord (i.e. generate an AC event) to get it to fix itself. Usually that's just temporary though and a full reboot is needed to make the machine sane.

Hardware is a Thinkpad R61 with a Core 2 processor.

cpufreq state when in this odd state:

[root@mjolnir cpufreq]# grep . scaling*
scaling_available_frequencies:2101000 2100000 1600000 1200000 800000 
scaling_available_governors:ondemand userspace performance 
scaling_cur_freq:800000
scaling_driver:acpi-cpufreq
scaling_governor:ondemand
scaling_max_freq:800000
scaling_min_freq:800000
scaling_setspeed:<unsupported>

Doing "echo 2101000 > scaling_max_freq" has no effect.


Not sure if the kernel is going crazy here or if it's some user space program that keeps constantly changing these values to their lowest setting. It's very annoying either way as it can make it impossible to do cpu intensive tasks like watching high resolution movies.
Comment 1 Pierre Ossman 2010-07-26 05:43:51 EDT
I enabled cpufreq debugging and got this when trying to change the max frequency:

cpufreq-core: setting new policy for CPU 0: 800000 - 2101000 kHz
freq-table: request for verification of policy (800000 - 2101000 kHz) for cpu 0
freq-table: verification lead to (800000 - 2101000 kHz) for cpu 0
freq-table: request for verification of policy (800000 - 800000 kHz) for cpu 0
freq-table: verification lead to (800000 - 800000 kHz) for cpu 0
cpufreq-core: new min and max freqs are 800000 - 800000 kHz
cpufreq-core: governor: change or update limits
cpufreq-core: __cpufreq_governor for CPU 0, event 3

So it looks like some kind of kernel and/or BIOS bug.
Comment 2 Pierre Ossman 2010-07-26 05:47:58 EDT
When transitioning from a working state to a broken, this is what I see in dmesg:

cpufreq_debug_printk: 143 callbacks suppressed
cpufreq-core: target for CPU 1: 2009652 kHz, relation 0
freq-table: request for target 2009652 kHz (relation: 0) for cpu 1
freq-table: target is 1 (2100000 kHz, 1)
cpufreq-core: notification 0 of frequency transition to 2100000 kHz
cpufreq-core: notification 1 of frequency transition to 2100000 kHz
cpufreq-core: target for CPU 1: 1050500 kHz, relation 0
freq-table: request for target 1050500 kHz (relation: 0) for cpu 1
freq-table: target is 3 (1200000 kHz, 3)
cpufreq-core: notification 0 of frequency transition to 1200000 kHz
cpufreq-core: notification 1 of frequency transition to 1200000 kHz
cpufreq_debug_printk: 100 callbacks suppressed
cpufreq-core: target for CPU 0: 800000 kHz, relation 0
freq-table: request for target 800000 kHz (relation: 0) for cpu 0
freq-table: target is 4 (800000 kHz, 4)
cpufreq-core: notification 0 of frequency transition to 800000 kHz
cpufreq-core: notification 1 of frequency transition to 800000 kHz
cpufreq-core: target for CPU 0: 2101000 kHz, relation 1
freq-table: request for target 2101000 kHz (relation: 1) for cpu 0
freq-table: target is 0 (2101000 kHz, 0)
cpufreq-core: notification 0 of frequency transition to 2101000 kHz
cpufreq-core: notification 1 of frequency transition to 2101000 kHz
cpufreq-core: setting new policy for CPU 0: 800000 - 2101000 kHz
freq-table: request for verification of policy (800000 - 2101000 kHz) for cpu 0
freq-table: verification lead to (800000 - 2101000 kHz) for cpu 0
freq-table: request for verification of policy (800000 - 800000 kHz) for cpu 0
freq-table: verification lead to (800000 - 800000 kHz) for cpu 0
cpufreq-core: new min and max freqs are 800000 - 800000 kHz
cpufreq-core: governor: change or update limits
cpufreq-core: __cpufreq_governor for CPU 0, event 3
cpufreq-core: target for CPU 0: 800000 kHz, relation 1
freq-table: request for target 800000 kHz (relation: 1) for cpu 0
freq-table: target is 4 (800000 kHz, 4)
cpufreq-core: notification 0 of frequency transition to 800000 kHz
cpufreq-core: notification 1 of frequency transition to 800000 kHz
cpufreq-core: setting new policy for CPU 1: 800000 - 2101000 kHz
freq-table: request for verification of policy (800000 - 2101000 kHz) for cpu 1
freq-table: verification lead to (800000 - 2101000 kHz) for cpu 1
freq-table: request for verification of policy (800000 - 800000 kHz) for cpu 1
freq-table: verification lead to (800000 - 800000 kHz) for cpu 1
cpufreq-core: new min and max freqs are 800000 - 800000 kHz
cpufreq-core: governor: change or update limits
cpufreq-core: __cpufreq_governor for CPU 1, event 3
cpufreq-core: target for CPU 1: 800000 kHz, relation 1
freq-table: request for target 800000 kHz (relation: 1) for cpu 1
freq-table: target is 4 (800000 kHz, 4)
cpufreq-core: notification 0 of frequency transition to 800000 kHz
cpufreq-core: notification 1 of frequency transition to 800000 kHz
Comment 3 Pierre Ossman 2010-07-26 07:10:00 EDT
Doesn't seem to be a thermal limit causing this problem:

$ cat /proc/acpi/processor/CPU0/limit 
active limit:            P0:T0
user limit:              P0:T0
thermal limit:           P0:T0
Comment 4 Pierre Ossman 2010-07-26 07:30:20 EDT
This might be a clue:

[root@mjolnir cpufreq]# cat bios_limit 
800000
[root@mjolnir cpufreq]# cat bios_limit 
2101000
Comment 5 Pierre Ossman 2010-07-26 07:58:13 EDT
That made the problem google:able, and I found this gem:

https://bugzilla.kernel.org/show_bug.cgi?id=16362
Comment 6 Chuck Ebbert 2010-07-27 17:03:43 EDT
Yeah, I guess we close this as notabug and point to the upstream note:

-> closing the bug "Resolved Documented"
ThinkPad people who see their system throttled as soon as the processor module
gets loaded and without obvious reason:
cat /sys/devices/system/cpu/cpu0/cpufreq/bios_limit
must pass processor.ignore_ppc=1 boot parameter as a workaround.
Comment 7 Chuck Ebbert 2010-08-06 16:20:42 EDT
*** Bug 611885 has been marked as a duplicate of this bug. ***

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