Bug 10055 - conservative governor doesn't increase frequency, just decrease. powernow-k7
Summary: conservative governor doesn't increase frequency, just decrease. powernow-k7
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-02-20 11:40 UTC by Erik Boritsch
Modified: 2011-01-18 05:43 UTC (History)
9 users (show)

See Also:
Kernel Version: 2.6.24.2-2.6.26
Subsystem:
Regression: Yes
Bisected commit-id:


Attachments
kern log for cpufreq scaling not working (14.30 KB, text/plain)
2008-07-29 02:04 UTC, Arthur Hagen
Details

Description Erik Boritsch 2008-02-20 11:40:22 UTC
Latest working kernel version:2.6.23.16
Earliest failing kernel version:2.6.24
Distribution:Gentoo
Hardware Environment:mitac 8375 Athlon XP-M 2800+

Problem Description: kernel 2.6.24.2, conservative governor compiled in (doesn't matter whether module or not). If I set conservative as current governor (either via cpufreq-utils or set it as default governor in kernel) the CPU frequency decreases slowly at low CPU load as it ought to be. But if I put the CPU on high load then,the frequency remains unchanged. 
Conservative is working on 2.6.23.*, ondemand works even on 2.6.24 CPU frequency module is powernow-k7 compiled in as module.

Steps to reproduce:
1.compile kernel with conservative governor
2.set it as current governor
3.put CPU on high load
Comment 1 Andrew Morton 2008-02-20 15:52:05 UTC
marked as a regression..
Comment 2 Dave Jones 2008-02-20 16:44:35 UTC
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.
Comment 3 Daniel Drake 2008-02-24 15:01:00 UTC
downstream bug report
https://bugs.gentoo.org/show_bug.cgi?id=210747
(identical, link for reference only)
Comment 4 Natalie Protasevich 2008-06-01 16:57:49 UTC
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.
Comment 5 Alexander Clouter 2008-06-01 17:19:25 UTC
Could you try the patch on:
http://bugzilla.kernel.org/show_bug.cgi?id=8081
Comment 6 Arthur Hagen 2008-07-29 01:37:02 UTC
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.
Comment 7 Arthur Hagen 2008-07-29 02:04:18 UTC
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.
Comment 8 Erik Boritsch 2008-08-17 08:35:09 UTC
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.
Comment 9 Arthur Hagen 2008-08-31 22:08:45 UTC
Confirmed still a problem with 2.6.26, also with Athlon 4-M (Erik has an Athlon XP-M).
Comment 10 Daniel Drake 2008-12-04 06:06:11 UTC
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
Comment 11 Erik Boritsch 2008-12-04 06:56:13 UTC
I don't have access to hardware right now, will hopefully get to it around Christmas. Will report here then.
Comment 12 aceman 2009-01-16 08:43:31 UTC
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.
Comment 13 aceman 2009-01-16 08:44:01 UTC
Ah, forgot to note I am using kernel 2.6.28 SMP.
Comment 14 Erik Boritsch 2009-09-10 03:21:43 UTC
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).
Comment 15 Len Brown 2011-01-18 05:42:20 UTC
> Works with kernel 2.6.30, default settings.  Whatever have caused this bug
> doesn't seem to be there anymore.

Thanks for testing.  Closed.

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