Starting around linux-2.6.30, there were kernel modifications that broke the "ondemand" CPU frequency scaling options (e.g. CONFIG_CPU_FREQ_GOV_ONDEMAND and CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND) from operating as they did in previous versions of linux. Reproducible: Always Steps to Reproduce: 1. Configure ONDEMAND frequency scaling in Linux kernel (CONFIG_CPU_FREQ_GOV_ONDEMAND=y / CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y) 2. Use the gnome panel "CPU Frequency Scaling Monitor" to monitor the CPU frequency. 3. Reboot system, login and monitor CPU. Actual Results: After linux kernel "enhancements" the CPU frequency would no longer scale-back. System log files, e.g. kern.log would accumulate errors of the form: "ondemand governor failed, too long transition latency of HW, fallback to performance governor" Expected Results: CPU *should* scale back the frequency (on a relatively lightly loaded Pentium IV Prescott, the frequency can scale back from 2.8 GHz to 350 MHz to 1.05 GHz with little impact on perceived performance) It takes a moderately loaded system (3 gnome sessions, multiple seamonkey / chrome sessions, 50+ tabs open, openoffice open with 4+ files, etc.) till the CPU "needs" 1.4-2.1 GHz and only portage ebuilds (or similar long running CPU intensive processes) really require the full 2.8 GHz. Note that this kernel feature provides *real* power savings to desktop systems (and $ savings from ones electric bill, not to mention the "green" perspective). The measured wall outlet power consumption dropped from ~135W to ~105W for the system when the clock speed transitions from high to low speed. The loss of this feature is due to change to ".../arch/x86/kernel/cpu/cpufreq/p4-clockmod.c" changing the default value that is assigned to "policy->cpuinfo.transition_latency" from "1000000" to "10000001". Why this change was allowed by the kernel developers isn't clear but it prevents significant power reductions across whatever fraction of the millions of Pentium IV's there are running recent versions of Linux around the world.
Created attachment 205908 [details] p4-clockmod.c:cpufreq_p4_cpu_init() with changes to correct problem The function is unchanged except for the segment involving the setting of "policy->cpuinfo.transition_latency". The "#ifdef NO_ONDEMAND" is the code found in Linux kernel's >= 2.6.30. The "#else" section is the older (IMO "correct") behavior. The entire function is provided so one can see the context. It isn't clear to me why this change was made (perhaps to support multi-core CPUs???) but it shows up as errors from ".../drivers/cpufreq/cpufreq.c" and the negatively impacts the use of the "cpufreq_ondemand.c" driver on older single-core CPUs.
The change in question entered the kernel in commit 36e8abf3edcd2d207193ec5741d1a2a645d470a5 from Dave Jones. His commit message states: [CPUFREQ] Prevent p4-clockmod from auto-binding to the ondemand governor. The latency of p4-clockmod sucks so hard that scaling on a regular basis with ondemand is a really bad idea. I cannot comment on the wisdom of this change, but the log message implies that the motivation was responsiveness, rather than concern about SMP systems.
I hate marking a well-composed bug report as this one as a duplicate but I'd like you to check bug #283646. If you have any questions or doubts on my judgement of closing this bug report, feel free to reopen it. Thanks :) *** This bug has been marked as a duplicate of bug 283646 ***
This bug was cited on the LKML 091025 with the subject: "Broken ondemand scheduler in Linux 2.6.30+ on Pentium IVs" People running into this may want to search there to see if any responses further explain this. Note to Kevin. I understand that the message indicates it may be dealing with a "responsiveness" issue, but I use this system on a daily basis and do not notice a problem with responsiveness -- even though as I type this the CPU is generally at 1.05 to 1.4 GHz rather than 2.8 GHz (running a large number of Seamonkey tabs with Javascript enabled will suck up CPU even when they are not effectively doing anything -- but thats a separate browser in general problem). Were I not running Seamonkey I believe CPU use would be at the 350-700 MHz level. (This is of course on a 2.6.31-r2 system with p4-clockmod.c returned to its functional state.)
I tried the Robert's p4-clockmod changhes and now ondemand governor returns to work. Is there any chance that this patch will be included in gentoo-sources?
(In reply to comment #5) > I tried the Robert's p4-clockmod changhes and now ondemand governor returns to > work. Is there any chance that this patch will be included in gentoo-sources? > Please, read the LKML thread that Robert posted: (http://preview.tinyurl.com/yj4pvnt). I don't think that Robert's patch is gonna be included into gentoo-sources, since there are many discussions against the use of ondemand with p4-clockmod. The solution is to use *acpi-cpufreq*.
(In reply to comment #6) > Please, read the LKML thread that Robert posted: > (http://preview.tinyurl.com/yj4pvnt). > > I don't think that Robert's patch is gonna be included into gentoo-sources, > since there are many discussions against the use of ondemand with p4-clockmod. > The solution is to use *acpi-cpufreq*. I tried acpi-cpufreq but it doesn't seem to work with mine processor (a p4 3ghz with ht), and I think I'm not the only one with this kind of problems so there's not another way to use ondemand cpufreq with my cpu.
Well, stating someone should "try XYZZY" is not the same as telling them how to do it. No man page on acpi-cpufreq, no binary reported by "which acpi-cpufreq" and no way to find out how one would enable/disable this from the desktop, e.g. the Gnome "CPU Frequency Scaling Monitor" (which IMO is quite a nice utility since it tells you at a glance what speed the CPU is at and indirectly what your power usage is). It looks like there is a CONFIG_X86_ACPI_CPUFREQ in the kernel but modprob'ing it gives a device/resource conflict on my system. It isn't clear when/if ACPI_CPUFREQ and P4_CLOCKMOD are mutually exclusive and/or whether it provides dynamic feedback to frequency monitors. If it really is a "fast" dynamic adjustment then I imagine that it requires updating the frequency on the monitor so frequently that it might increase the CPU load.
The problem is still there with 2.6.31-r6 kernel , using the p4-clockmod modifications by Robert fixes the issue also for 2.6.31-r6
(In reply to comment #9) > The problem is still there with 2.6.31-r6 kernel , using the p4-clockmod > modifications by Robert fixes the issue also for 2.6.31-r6 > and I cannot load acpi-cpufreq module since it gives : No Such Device error
I ran into the same problem so I tried to force CONFIG_X86_CPUFREQ=y to force it into the kernel. That in turn led me to conclude that ACPI_PROCESSOR may also need to be forced to be included (vs a module) [I've got ACPI_FAN and ACPI_THERMAL included as well though I'm not sure if those are required.] Note that YMMV as I haven't rebooted 2.6.31-gentoo-r6 to see if I get the scaling I want. There doesn't appear to be much documentation on how to properly setup CPUFREQ & ACPI in the documentation but some of the comments in user-guide.txt (which I only briefly scanned) caused me to wonder if your laptop is either using an older model Celeron chip or a really flakey BIOS. In those cases you may not be able to use the ACPI approach. It would be REALLY nice if someone would post a *real* working .config with the ACPI_CPUFREQ driver on a standard (preferably several year old) Intel P4.
The same happens here on an athlon-xp, here is what I see inside dmesg: [ 0.178547] cpufreq-nforce2: Detected nForce2 chipset revision A2 [ 0.178550] cpufreq-nforce2: FSB changing is maybe unstable and can lead to crashes and data loss. [ 0.178561] cpufreq-nforce2: FSB currently at 166 MHz, FID 13.0 [ 0.178578] ondemand governor failed, too long transition latency of HW, fallback to performance governor [ 0.178585] Marking TSC unstable due to cpufreq changes A couple more info: grep ACPI /boot/config # Power management and ACPI options CONFIG_ACPI=y CONFIG_ACPI_SLEEP=y # CONFIG_ACPI_PROCFS is not set CONFIG_ACPI_PROCFS_POWER=y CONFIG_ACPI_SYSFS_POWER=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=y # CONFIG_ACPI_BATTERY is not set CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y CONFIG_ACPI_DOCK=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y # CONFIG_ACPI_CUSTOM_DSDT is not set # CONFIG_ACPI_CUSTOM_DSDT_INITRD is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set # CONFIG_ACPI_PCI_SLOT is not set # CONFIG_ACPI_CONTAINER is not set # CONFIG_ACPI_SBS is not set CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_POWERNOW_K7_ACPI=y CONFIG_PNPACPI=y CONFIG_ATA_ACPI=y # CONFIG_PATA_ACPI is not set grep CPUFREQ /boot/config CONFIG_X86_ACPI_CPUFREQ=y CONFIG_X86_CPUFREQ_NFORCE2=y # CONFIG_X86_CPUFREQ_EEEPC900 is not set I can't say it worked before because I have this pc since less than a week. Using just ACPI_CPUFREQ doesn't work, cpufreqd complains about the missing driver. Looking at the discussion on google groups made me curious about the specific file, arch/x86/kernel/cpu/cpufreq/cpufreq-nforce2.c which, at line 367, shows policy->cpuinfo.transition_latency = CPUFREQ_ETERNAL; and this really seems to be the cause for that 'too long transition latency of HW' in dmesg. Changing the value to "1000000; /* assumed */" (as in the discussion on google groups) made it work.
Tommaso, you really need to be very very careful between power consumption issues between the primary CPU (presumably x86-whatever) and the GPU (nvidia-AMD-whatver). They involve very different modules. You can presumably view a graphic card as a few to dozens of CPU's placing a load on power requirements until such time as reversible computing is available (http://en.wikipedia.org/wiki/Reversible_computing). And we are quite a long ways away from that. As ACPI tended to evolve before the various graphics card options the cards/interfaces may or may not be subject to its requirements. This particular bug is about the changing of p4-clockmod.c by some hell-bent kernel developer to optimize his scrolling speed in the face of other users who want actual *real-time* feedback with respect to what the (primary!) CPU is doing *which* is what Gnome Frequency Monitor Utility provided.
You're right, I should have mentioned: my motherboard doesn't provide an integrated GPU, so all messages regarding nforce2 are related to the chipset. The GPU is actually a Geforce fx5500 which I still have to check about power management (I still haven't finished compiling X+Gnome). As things were yesterday evening, cpufreqd started but the frequency stayed still at 2.17Ghz with the performance governor; cpufreq-info showed that the cpu could go as down as 1.52GHz (obviously not with the performance governor). I wasn't able to change governor to ondemand, but with your suggestions about cpuinfo.transition_latency I had it back working, so, even if I have a different cpu than yours, I think the issue I see is related to yours, am I wrong?
I've got an interesting spin on this. Now (linux-2.6.31-gentoo-r6) can't even start cpufreqd -- it says "cpufreqd requires the kernel to be configured with CONFIG_CPU_FREQ" Yet if I look at my .config file, I have: CONFIG_CPU_FREQ=y CONFIG_CPU_FREQ_TABLE=y # CONFIG_CPU_FREQ_DEBUG is not set # CONFIG_CPU_FREQ_STAT is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y # CONFIG_CPU_FREQ_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_GOV_USERSPACE is not set CONFIG_CPU_FREQ_GOV_ONDEMAND=y # CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set This is with an unmodified p4-clockmod.c (in a vain attempt at trying to use an as distributed kernel). I'm reopening this bug so we can get some more feedback on either (a) How to tell how much the ACPI<->BIOS frequency lowering / power saving is actually taking place; or (b) we get told that the ACPI<->BIOS frequencies cannot be monitored and thus the only choice is to return to the p4-clockmod.c modification if we desire to have some user can actually see what is going on. There is a reason for this -- there are often occasions where power consumption gets spiked due to browser activity (abuse of Flash by advertisers being the most common example of this) and I want to know this when my CPU is running at 2.8 GHz instead of a more typical average speed of <= 800 MHz (which provides more than adequate performance for "typical" activities).
we do really need a fully functional p4-clockmod. THere are lots of us that cant use the acpi_cpufreq module. It locks up my system completely when switching freqs.. (ie going to battery) . Most of the systems that do this are older systems and arent getting bios updates anymore either.
update: after more testing with many kernels I was finally able to get 2.6.33-rc2-git5 acpi-cpufreq working as desired. :) So for now bye p4-clockmod. Sorry for the noise on this bug
The comments are not "noise" until somebody explains to me how one gets gnome to use the Gnome CPU Frequency Scaling Monitor to work with ACPI-cpufreq. I've got that built into my current kernel but I have *NO* idea how to see how much CPU time is actually being used (or even tell if its working) I've tried working through the power saving documentation but so far that has yielded nothing. The entire point of this is that p4-clockmod and cpufreq scaling have monitoring tools compatible with gnome that do not appear to be compatible with ACPI-cpufreq. So you have no real idea as to how much power ones machine is consuming in real time. I have a power monitor but I don't want leave it installed 24/7 on my PC -- and have documented that one saves about 20W of wall outlet power when the 2.8GHz CPU drops back to the minimum speed. I want to *KNOW* when a Firefox or a Chrome session get too power hungry (their power consumption (related to CPU consumption) goes up with the size of the session -- unlike gnome-terminal where one could run an extremely large number of them without impacting system performance or power consumption in any way, thus evidence for the still-flawed design of Firefox/Chrome (though I'm starting to reach the conclusion that Chromes degradation (in power use) is less than that of Firefox's with session size (if configured properly). The current situation suggests that I should make my correction to the current kernel version, go back to using p4-clockmod, and mask all upgrades to gentoo-sources (and forego ever upgrading a Linux kernel again -- or at least until someone explains to me how to monitor my real-time clock speed ~= power use using current gnome tools.
http://lkml.org/lkml/2009/10/26/558 From upstream: "If your system and CPU actually support CPU frequency scaling then p4-clockmod isn't the driver that should be being used, acpi-cpufreq is the one on most systems."
If one gets a "No such device" error when "modprobing" acpi-cpufreq, one cause may be: Linux Code: drivers/acpi/processor_perflib.c: static int acpi_processor_get_performance_control(struct acpi_processor *pr) ... status = acpi_evaluate_object(pr->handle, "_PCT", NULL, &buffer); if (ACPI_FAILURE(status)) { ACPI_EXCEPTION((AE_INFO, status, "Evaluating _PCT")); return -ENODEV; } If one dumps the ACPI Bios using the Intel/Debian program acpidump and then converts the .dat files to ACPI .dsl files using iasl (Intel ACPI Component Architecture) program" one may find that ones ACPI BIOS lacks a "_PCT" section. According to the "Intel Processor Vendor-Specific ACPI" Interface Specification dated September 2006, the _PCT (Performance Control) hardware option is *ONLY* provided on processors with "Enhanced" Intel SpeedStep(R) Technology. Thus there appears to be no way for standard desktop Pentium IV (Prescott) CPUs, which to the best of my knowledge lack "Enhancement", e.g. vendor_id : GenuineIntel cpu family : 15 model : 3 stepping : 4 cpu MHz : 2800.938 cpuid level : 5 to use acpi-cpufreq (ACPI BIOS) to control the CPU speed (and indirectly its power usage). One apparently cannot use acpi-cpufreq on Pentiums without "Enhanced" SpeedStep(R). As there have to be millions, perhaps tens of millions, of these processors it is therefore WRONG to suggest that acpi-cpufreq is the "right" way to control power usage for Pentium IV Prescott's. For these processors without modifications to the acpi drivers and potentially even the ACPI BIOS of the machine (which makes CONFIG_ACPI_CUSTOM_DSDT and http://www.lesswatts.org/projects/acpi/overridingDSDT.php rather interesting) the cpufreq-ondemand driver with p4-clockmod.c is the correct way to minimize power use [1]. A reasonable solution for this for p4-clockmod.c to leave the transition latency at 1000000 on non-Enhanced CPUs instead of the recent modification changing it to 10000001. Some of the notes in the ACPI Architecture documentation lead me to believe it is possible to detect these CPUs and have the driver act accordingly. Ultimately this bug needs to be booted *back* upstream to the kernel developers to point out that there are millions of machines where the "current" solution is highly undesirable. These comments are based on the current kernel "2.6.34-gentoo". 1. Not having an "Enhanced" Pentium at my disposal it is impossible for me to see whether I could dump the ACPI BIOS, find a _PCT section and see if it could be hacked into working with the non-Enhanced Pentiums with a custom DSDT.
Created attachment 235403 [details] Linux .config info, log file diagnostics, emerge --info. /proc/cpuinfo This pretty much tells you how to configure your system and read the log files to determine if one has a Intel CPU and/or ACPI BIOS which will not support the acpi-cpufreq module as currently distributed in linux-2.6.34.
Robert, what's going on with one?
I've attempted to add comments and pointers to Kernel Bug #'s 12482, 14771 and 16072. Other people continue to encounter the problem. It appears that it arose due to naive developers circa Linux 2.6.30 thinking that everyone in the world runs Intel Enhanced SpeedStep processors combined with motherboards where the ACPI BIOS has _PCT sections -- which would allow acpi-cpufreq to function. Without both of those it appears that one has to use p4-clockmod and tune the clock frequency transitions on a "user environment" basis. My patch works but a more elegant solution requires the ondemand scheduler and esp. p4-clockmod.c set "policy->cpuinfo.transition_latency" based on both the CPU type (which determines whether one has enhanced speedsetp) *and* whether the ACPI BIOS has the _PCT support (which I would imagine isn't a "lightweight" change due to cross-module dependencies). From where I sit it involves the Kernel developers taking a bit more seriously the numbers of legacy CPUs and Motherboard / BIOS combinations that may exist and allow for them (at least if one is going to pay some lip service to being GREEN). (*) It might be possible to work around this for people who have old BIOS + new (enanced) CPU combinations if they want to hack their ACPI DSDT tables to include _PCT sections -- it appears the kernel still allows "CONFIG_ACPI_CUSTOM_DSDT" to include a custom DSDT file -- but I don't have an example of such a ACPI BIOS table nor do I believe that a Pentium IV Prescott (w/ SpeedStep but w/o Enhanced SpeedStep?) would work with one anyway. * Currently running a Pentium IV Prescott CPU with a hacked p4-clockmod.c on Linux 2.6.34-gentoo-r1 which will drop from 2.8 GHz to 350 MHz much of the time (reducing power consumption from ~135W to ~105W).
I have Pentium 4 Northwood (no speed AFAIK) and a P4S333-VM with latest bios. acpi-cpufreq doesn't work and p4-clockmod worked since 2.6.29 Here's what I get with cpufreq.debug=4 "conservative governor failed, too long transition latency of HW, fallback to performance governor" This is a regression please fix/make it fix.
Created attachment 249286 [details, diff] Robert's function as a patch
*** Bug 339094 has been marked as a duplicate of this bug. ***
Resolving as upstream as per bug 16072
Just a warning/note. Starting around linux-2.6.36-gentoo-r5 (2.6.36?) the kernel source for p4-clockmod.c deleted 4 lines (182-185) so any patch that depends on line numbers may have to be updated to work with newer kernels. It looks like one can use an old p4-clockmod.c (e.g. an old patched 2.6.30-2.6-35 version) without it causing problems (I link all my kernel sources with identical files together and then simply drop in the p4-clockmod.c from the current /usr/src/linux/ to replace any newer one distributed by the kernel developers/gentoo). This strategy may fail if p4-clockmod.c changes significantly in the future but that is unlikely IMO.
(In reply to comment #27) > Resolving as upstream as per bug 16072 In what version of kernel??? Here with .38 does not work like precedent version. cpufreq-set -c 0 -g ondemand do nothing. I see availability of ondemand but governor remains performance
Take this upstream.
