Bug 10055
Summary: | conservative governor doesn't increase frequency, just decrease. powernow-k7 | ||
---|---|---|---|
Product: | Power Management | Reporter: | Erik Boritsch (borych) |
Component: | cpufreq | Assignee: | cpufreq (cpufreq) |
Status: | CLOSED UNREPRODUCIBLE | ||
Severity: | normal | CC: | acelists, alex, art-kbt, davej, kernel, lenb, protasnb, tcunha, trenn |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.24.2-2.6.26 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Attachments: | kern log for cpufreq scaling not working |
Description
Erik Boritsch
2008-02-20 11:40:22 UTC
marked as a regression.. Most obvious candidate for a problematic diff would be this patch I guess.. commit 1c2562459faedc35927546cfa5273ec6c2884cce Author: Thomas Renninger <trenn@suse.de> Date: Tue Oct 2 13:28:12 2007 -0700 [CPUFREQ] allow ondemand and conservative cpufreq governors to be used as default Depending on the transition latency of the HW for cpufreq switches, the ondemand or conservative governor cannot be used with certain cpufreq drivers. Still the ondemand should be the default governor on a wide range of systems. This patch allows this and lets the governor fallback to the performance governor at cpufreq driver load time, if the driver does not support fast enough frequency switching. Main benefit is that on e.g. installation or other systems without userspace support a working dynamic cpufreq support can be achieved on most systems by simply loading the cpufreq driver. This is especially essential for recent x86(_64) laptop hardware which may rely on working dynamic cpufreq OS support. Looking through it though, I'm not entirely clear how it could be at fault. downstream bug report https://bugs.gentoo.org/show_bug.cgi?id=210747 (identical, link for reference only) Eric, is this still a problem with current kernel? If so, you can try enabling CPU_FREQ_DEBUG in the config and either boot with cpufreq.debug=X or load cpufreq with debug=X parameter, where X is 1(core) 2(driver) or 4(governor) debug. Could you try the patch on: http://bugzilla.kernel.org/show_bug.cgi?id=8081 Still a problem with 2.6.25 Alex: This is NOT the same bug as with conservative climbing extremely slowly due to a high scaling_min value. In this case, it will not climb AT ALL -- even hours pegged at 100%, and it will stay at the same frequency. The bug you reference also appeared much earlier -- this one appeared with 2.6.24, and 2.6.23 is fine. Created attachment 17022 [details]
kern log for cpufreq scaling not working
Kernel log for cpufreq conservative scaling not working, cpufreq.debug=7. For the last few minutes of this log, the CPU was pegged at 95-100%, yet the frequency stood still at the lowest possible value.
The problem is still there with 2.6.26. Conservative governor refuses to increase frequency. It is a critical issue for me as I have a buggy CPU which hangs if the frequency is increased from minimum to the maximum i.e. I can't use ondemand. Confirmed still a problem with 2.6.26, also with Athlon 4-M (Erik has an Athlon XP-M). Erik, do you have time to do a bisection? This would find the exact commit which introduced the bug. See the process here: http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ Use v2.6.23 as good and v2.6.24 as bad I don't have access to hardware right now, will hopefully get to it around Christmas. Will report here then. How many frequency levels does your CPU have? I can also see this on my AMD Phenom quad core (family 10). I only have 2 levels - 1000Mhz and 2000Mhz. Once down, the conservative governor never increases it up. On the other hand, the frequency is only decreased when there is no load on the particular core (each core can have a different frequency and governor, but governor setting are shared). I use the powernow-k8 driver. However, it works when setting freq_step to "50" or more. The ondemand governor works fine with the default settings, increases and decreases the frequency as needed. Ah, forgot to note I am using kernel 2.6.28 SMP. Works with kernel 2.6.30, default settings. Whatever have caused this bug doesn't seem to be there anymore. Will test 2.6.31 somewhere this week (have access to the machine again). > Works with kernel 2.6.30, default settings. Whatever have caused this bug
> doesn't seem to be there anymore.
Thanks for testing. Closed.
|