Bug 10564 - Randomly sets max freq equal to min freq
Summary: Randomly sets max freq equal to min freq
Status: CLOSED UNREPRODUCIBLE
Alias: None
Product: Power Management
Classification: Unclassified
Component: cpufreq (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: cpufreq
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-27 09:11 UTC by Scott
Modified: 2011-07-06 19:28 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.24/25
Tree: Mainline
Regression: Yes


Attachments

Description Scott 2008-04-27 09:11:14 UTC
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.
Comment 1 Andrew Morton 2008-04-27 09:35:33 UTC
Is this a regression?  Did any earlier kernel work OK?  If so, which version?

Thanks.
Comment 2 Andrew Yates 2008-04-27 10:14:27 UTC
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.
Comment 3 Scott 2008-04-27 10:30:14 UTC
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.
Comment 4 Andrew Yates 2008-04-27 11:35:09 UTC
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).
Comment 5 Andrew Yates 2008-04-27 11:38:08 UTC
I forgot to mention that I get the same behavior with the userspace governor; I had forgotten to load the module above.
Comment 6 Thomas Renninger 2008-04-28 08:26:18 UTC
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...
Comment 7 Scott 2008-04-28 11:54:58 UTC
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.
Comment 8 Thomas Renninger 2008-04-30 03:29:35 UTC
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?
Comment 9 Scott 2008-05-03 07:41:06 UTC
I just tried 2.6.25-git19, which has the above cpufreq commit, and still observe the problem. 
Comment 10 Scott 2008-05-03 08:13:13 UTC
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.
Comment 11 Thomas Renninger 2008-05-03 09:50:00 UTC
> 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...
Comment 12 Len Brown 2011-01-18 06:03:05 UTC
no update in 2 over years.
please re-open if this is still a problem with a recent kernel.
Comment 13 Joaquín Aramendía 2011-07-06 19:28:27 UTC
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.

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