Dell Latitude C400 i686 Mobile Intel(R) Pentium(R) III CPU - M 1200MHz GenuineIntel GNU/Linux Usually within 5 minutes of booting up, after the computer has been off while I'm at work or sleeping, cpufreq will suddenly revert to the lowest freq and remain stuck in it. Before this happens, scaling works fine. I'm using the ondemand governor. I can reboot (the only way to fix it) and then it will typically work fine - up until I shut down for another longish period of time and boot up again. Here's cpufreq debug output where it changes: cpufreq-core: updating policy for CPU 0 cpufreq-core: setting new policy for CPU 0: 800000 - 1200000 kHz acpi-cpufreq: acpi_cpufreq_verify acpi-cpufreq: acpi_cpufreq_verify 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 acpi-cpufreq: acpi_cpufreq_target 800000 (0) cpufreq-core: notification 0 of frequency transition to 800000 kHz cpufreq-core: notification 1 of frequency transition to 800000 kHz $ grep "" /sys/devices/system/cpu/cpu0/cpufreq/* /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:0 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1200000 /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:800000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:1200000 800000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:userspace 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:800000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:800000 /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:<unsupported> Let me know if I should provide anything else, since it's easily reproducible. It's been occurring for the last 2-3 months and is pretty much unusable in this state, so I've been rebooting often.
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.