Bug 618149
| Summary: | cpufreq sometimes stuck at lowest frequency | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Pierre Ossman <pierre-bugzilla> |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 13 | CC: | anton, dougsland, gansalmon, itamar, jonathan, kernel-maint, krlynch, madhu.chinakonda |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-07-27 21:03:43 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Pierre Ossman
2010-07-26 09:24:46 UTC
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. *** |