Red Hat Bugzilla – Bug 618149
cpufreq sometimes stuck at lowest frequency
Last modified: 2010-08-06 16:20:42 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.
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.
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
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
This might be a clue: [root@mjolnir cpufreq]# cat bios_limit 800000 [root@mjolnir cpufreq]# cat bios_limit 2101000
That made the problem google:able, and I found this gem: https://bugzilla.kernel.org/show_bug.cgi?id=16362
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.
*** Bug 611885 has been marked as a duplicate of this bug. ***