Bug 10564
| Summary: | Randomly sets max freq equal to min freq | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | Scott (stonecrest) |
| Component: | cpufreq | Assignee: | cpufreq (cpufreq) |
| Status: | CLOSED UNREPRODUCIBLE | ||
| Severity: | normal | CC: | akpm, andrew, davej, lenb, samsagax, venki |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.24/25 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
|
Description
Scott
2008-04-27 09:11:14 UTC
Is this a regression? Did any earlier kernel work OK? If so, which version? Thanks. I have the same problem, but with this CPU: Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz For me, the problem can sometimes be triggered by removing the battery while the AC is plugged in. With both battery and AC, cpufreq works as normal, but when I remove the battery I cannot set a frequency higher than 1.2GHz. I did not notice this problem before 2.6.24.2, but I started using this laptop soon before .24.2 was released so I cannot confirm whether or not it's a regression. Andrew, Yes it's a regression, cpufreq scaling has worked properly for years with this laptop. I'm unsure which kernel version it started with (I'd guess it's around 2.6.24), but I'll do some testing with different versions and see if I can narrow it down. I should point out that the summary ("Randomly sets max freq equal to min freq") is not entirely correct in my case.
My min freq is 800mhz and max is 2.5ghz. cpufreq refuses to set any speed higher than 1.2ghz, which is one step up from my minimum. Any attempts to set the CPU to a frequency higher than 1.2ghz fail, but I can change between 1.2ghz and 800mhz.
$ grep "" /sys/devices/system/cpu/cpu0/cpufreq/*
/sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 1
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:2501000
/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/phc_controls:77:41 76:34 10:30 8:27 6:23 136:19
/sys/devices/system/cpu/cpu0/cpufreq/phc_default_controls:77:41 76:34 10:30 8:27 6:23 136:19
/sys/devices/system/cpu/cpu0/cpufreq/phc_default_vids:41 34 30 27 23 19
/sys/devices/system/cpu/cpu0/cpufreq/phc_fids:77 76 10 8 6 136
/sys/devices/system/cpu/cpu0/cpufreq/phc_version:0.3.0
/sys/devices/system/cpu/cpu0/cpufreq/phc_vids:41 34 30 27 23 19
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:2501000 2500000 2000000 1600000 1200000 800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:ondemand performance
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:acpi-cpufreq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1200000
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:800000
$ cpufreq-info
cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to linux@brodo.de, please.
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which need to switch frequency at the same time: 0 1
hardware limits: 800 MHz - 2.50 GHz
available frequency steps: 2.50 GHz, 2.50 GHz, 2.00 GHz, 1.60 GHz, 1.20 GHz, 800 MHz
available cpufreq governors: ondemand, performance
current policy: frequency should be within 800 MHz and 1.20 GHz.
The governor "ondemand" may decide which speed to use
within this range.
current CPU frequency is 800 MHz (asserted by call to hardware).
I forgot to mention that I get the same behavior with the userspace governor; I had forgotten to load the module above. Could this be a duplicate of: http://bugzilla.kernel.org/show_bug.cgi?id=9708 Do you both use acpi-cpufreq? If yes, the patch there should be added. Dave asked me to send him a reminder (should have done so last weeek...), hope adding you here is enough... Yes, we both use acpi-cpufreq. For what it's worth, I always use my laptop plugged into AC, so hopefully that other bug report is not specific to switching power state. I'll be happy to test a kernel with this patch, thanks for pointing it out. commit e56a727b023d40d1adf660168883f30f2e6abe0a Author: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Date: Mon Apr 28 15:13:43 2008 -0400 [CPUFREQ] Make acpi-cpufreq more robust against BIOS freq changes behind our back. If this does not help, I wonder whether ignore_ppc=1 as processor module parameter helps? I just tried 2.6.25-git19, which has the above cpufreq commit, and still observe the problem. I also now tried ignore_ppc=1. This is interesting, as cpufreq-info shows the correct min/max frequencies, but I can tell that the issue is definitely not resolved. Things were normal when I first booted up, but now I'm back to the system not even being able to keep up with my typing and everything sluggish. So despite cpufreq-info reporting the correct max freq, I don't know that anything else fundamentally changed. It looks like there are a number of people with this issue (http://bbs.archlinux.org/viewtopic.php?pid=363228#p363228), and they claim it started with the 2.6.24 kernel. That's consistent with what I guessed, although I have not yet verified that this was definitely the kernel version where things changed. And I should note that I'm testing on the mainline kernel without patches, despite the reference to Archlinux. > but now I'm back to the system not even being able to keep up with my typing
> and everything sluggish.
Puhh, could be the latest locking changes? Maybe irqs are held too long or similar?
Scott, if you could do a git bisect, as you already know about which kernel versions are affected it shouldn't be that much work...
If you could tell Venkatesh which patch it is then, it should be easy to fix.
You should spinlock debug compile in, maybe you already get a hint that somewhere things get stuck for a while...
no update in 2 over years. please re-open if this is still a problem with a recent kernel. This is still present. Came across this issue the first time on December 2010 but did not give much importance since it happened once or twice. Here is a report happening to a recent machine. https://bugs.archlinux.org/task/18815 But dropped since the user changed fans. This "stuck" seems to be related with high load on processors all at once (high demanding multithreaded tasks shuch as compiling OpenCascade or video/audio encode). Happened in such cases but not exclusively, when suspending too (sometimes, not allways). Also the fans are forced to go at maximum even when the temperature is not high. Really is annoying and slows the machine a lot. Normally the processor is "unstuck" after a cold boot (rebooting does not fix the "stuck"). My specs: Dell Vostro 3500. A10 BIOS version. Intel core i5-460M (2.53GHz - 2.8GHz w/TurboBoost) Using modules: $ lsmod | grep -i freq cpufreq_powersave 1030 0 cpufreq_ondemand 6172 4 acpi_cpufreq 5809 1 freq_table 2491 2 cpufreq_ondemand,acpi_cpufreq mperf 1315 1 acpi_cpufreq processor 24328 1 acpi_cpufreq Any other info please let me know. |