acpi-cpufreq/powernow-k8 should not be built-in into the kernel image

+1

+1 (please!)

+1 as well...

To actually add some more reason: I own a AMD based system. Because acpi-cpufreq is build into the kernel, loading it actually SLOWS DOWN booting my system. The only drivers that should be considered to be build in, are modules required to boot! acpi-cpufreq and powernow-k8 are never required to boot a system!

There are probably over 1000 Ubuntu users that are actively using PHC modules to lower their systems power consumption or even to unlock more cpu scaling frequencies... So please solve this issue ASAP.

I have a Raon Digital Everun Note UMPC and I need to replace the not working powernow-k8 code with a code that at least makes the conservative governor work.

Currently the Turion X2 TL-56 is always running at 1200 MHz instead of 800 MHz. This results in 70 minutes battery life instead of 115 mins. I'm seriously considering to change to another distribution.

The code that is at least partially working (ondemand and userspace crash the system) can be found here. http://www.schugy.de/Linux/Raon%20Everun%20Note/powernow-k8-src.zip

Thanks for any support!

I'm having the same problem, I have been undervolting my laptop since at least feisty fawn which has always worked for me within an hour after upgrading to a new version of Ubuntu. Unfortunately this is not possible anymore because it is build in now.

I think, allthough I know it is easy to say this yet hard to get this completely right, only the modules that are essential to booting should be compiled in. Is there anyone who can tell if this is a big change? To me it sounds like just a small fix?

I am in the same boat as most ppl above. I have been using ubuntu since breezy and undervolting the AMD Turion on my laptop since feisty. Usually I check to make sure the usual suspects (X, suspend/hibernate) have no issues before upgrading but did not think something basic as acpi/powernow would be changed!

Undervolting saves battery life, cpu temperature and my hands (from CTS).

It'll be good to have this back as a module and not in the kernel.

For what it's worth, it is in commit 495f78bd6d8f7a5e35dd962031eb6e639d83e438, which IMHO should be reverted:

   UBUNTU: Build in CPU Frequency scaling drivers

    Selecting the right CPU Frequency scaling driver is complicated from
    userspace, involing a nasty shell script that attempts to guess by
    grepping through /proc.

    The kernel drivers themselves can adequately determine whether they
    should be used, building them into the kernel will automatically select
    the right one.

    These aren't something you would want to unload either, you would
    instead simply change the governor.

    rtg - Added debian/abi/2.6.28-8.23/modules.ignore to accomodate the missing modules.

    Signed-off-by: Scott James Remnant <email address hidden>
    Signed-off-by: Tim Gardner <email address hidden>

- First of all, the kernel does not (and simply cannot) always adequately determine which one is the best driver to use for someones hardware (especially when choosing between speedstep-centrino and cpufreq-acpi). And even if it does, so would lets-modprobe-just-about-any-driver do.

- They are something you would want to unload in realistic situations, especially since:
  * Some people prefer NOT to have a cpufreq driver, that's why it is a config option in the first place. There are systems known to consistently trigger a "pending-bit stuck" when using the powernow-k8 driver.

  * AFAIK the Ubuntu team wants to achieve a faster boottime, not slower. Compiling in all drivers slow down booting noticeably. You don't need them to boot either, so they can be postponed until a bit later.

  * Newer processors may not be supported until a new kernel is distributed, unless a custom module can be loaded. This is true for AMD 0xf family processors with more than 1 low power state. Also for all Black Edition AMD processors, the powernow-k8 driver does not support using their unlocked multiplier and probably never will because AMD doesn't want that feature in their powernow-k8 driver. The Linux-PHC project provides such drivers that can be installed/maintained by the DKMS.

  * You may want to use a modified module, that enables undervolting, to maximize their battery life or reduce extreme heat by reducing the processor's power consumption. The Linux-PHC project provides such drivers. There is a large audience that uses them...

Tim Gardner is responsible for introducing this, assign him to this bug.

+1 from another AMD Turion and PHC user trying to reduce CPU temperature (50C -> 30C) and extend battery life.

I would really like to keep using Ubuntu, but compiling a custom kernel to enable undervolting is very time-consuming and could convince me to switch to another distro.

Thanks in advance.

Is there any news on this issue, to me it looks like a very small fix as no code has to be adjusted.

I don't know anything about the processes behind such a change and I could be wrong saying this isn't a lot of work to fix, I'm just trying to see what the odds are of this bug making it into 9.10/Karmic.

+1 from me too

I have a AMD Phenom II Black Edition and want to optimize my system through custom Cool'n'Quiet. I undervolt my processor on lower power states and overclock a little bit with default voltage on highest power state. This allows me to lower power consumption in idle and also get higher performance if I need it.

Andy - we should consider pulling these frequency governors back out.

Ok we moved them in so we could get rid of userspace lash up to get them loaded under the commit below which appears to have originated from Scott. I assume in the "no rules in userspace" land we find ourselves we would need to find some kind of module alias match up to make these modularisable. Will have a look if we have anything already or whether its easy to get something produced:

commit 495f78bd6d8f7a5e35dd962031eb6e639d83e438
Author: Tim Gardner <email address hidden>
Date: Wed Feb 18 07:51:12 2009 -0700

    UBUNTU: Build in CPU Frequency scaling drivers

    Selecting the right CPU Frequency scaling driver is complicated from
    userspace, involing a nasty shell script that attempts to guess by
    grepping through /proc.

    The kernel drivers themselves can adequately determine whether they
    should be used, building them into the kernel will automatically select
    the right one.

    These aren't something you would want to unload either, you would
    instead simply change the governor.

    rtg - Added debian/abi/2.6.28-8.23/modules.ignore to accomodate the missing

    Signed-off-by: Scott James Remnant <email address hidden>
    Signed-off-by: Tim Gardner <email address hidden>

Andy, i know where you live.

If you revert these to modules, I will hunt you down and kill you.

kthxbye

A better approach for the out-of-kernel issue would be to have a kernel command-line option to select or disable frequency scaling drivers, e.g. just

    scaling_driver=acpi-cpufreq
or
    scaling_driver=none

Then users can load another module later if they want.

One major reason these have to be built-in is that much of the "which driver do we use?" code is raw assembler and machine instructions in each of the drivers, that know the precise magic. (Fundamentally they try and enable their particular blend of scaling, and see if it works). In userspace, the only way to replicate this would be to force-load all of the modules anyway (in the right order, which again duplicates information already known to the kernel source). We always got this wrong.

Another key point is that many processors come up in their lowest power/speed mode by default; only by loading the cpu frequency scaling early can we nail the driver to performance during boot. (performance is our default governor for precisely this reason). If we delay to later in the boot, we have half the boot on the lower power/speed.

First of all, such a kernel command-line option would be great... It will be a nightmare to write it and maintain it though. Go ahead and try to do it, please! I honestly would be thankful. I doubt it will be in time for Lucid...

Loading all modules is what is already done, except the modules are built-in. So that "major reason" is invalid. Actually, it can only get better than what we are now at (some cpu's are supported by both speedstep and acpi-cpufreq, and there isn't a best one in all situations and the acpi-cpufreq driver actually tries to support any processor, but fortunately it can't). It's not all "code that is raw assembler and ... know the precise magic". Every current processor (Intel, AMD and VIA) has its northbridge integrated, so all you have to do is look at the PCI ids, you can even get udev to it automatically (and decide what's best for some corner cases).

About your "key point", please point me one processor that comes with their lowest frequency enabled?! In contrary, a lot of AMD systems are actually better of without cpufreq support, because their "Black Edition" often has a higher multiplier enabled in the BIOS than what the vanilla powernow-k8 driver supports. So after loading the powernow-k8 driver, you will never get back that higher frequency setting.

(By the way, all applicable cpufreq drivers are written completely in C.)

just because of this i built my own kernel on lucid
2.6.33, built with kernelcheck - with some hacks to make it work (patched kernelcheck, adapted grub, blacklisted nouveau in favour of nvidia)

it turned out i just needed a current version of mplayer to watch 1080p movies without overclocking. nevertheless i'd like to have the full 3,2 GHz with speedstep enabled

Just to keep things together and make you notice that more people care about this topic:

http://brainstorm.ubuntu.com/idea/24567/

What we really need is a "noload" parameter in that module... I'd imagine it should be relatively simple to have the driver abort (or do nothing and return "success") if that parameter is set to true.

@ Dana Goyette
Even if that's possible, I don't think it's a good idea. The whole module architecture was made specifically for the case of loading and unloading them, and it's not good to have another way of basically doing the same thing.

@Scott James Remnant
"Andy, i know where you live.

If you revert these to modules, I will hunt you down and kill you.

kthxbye"
Even if it's meant as a joke, it's not funny.

The problem is what it is. The module should not be compiled in the kernel in the first place! I don't understand why it is so hard to have one module not built in. It might take 0.001 seconds longer to load and will offer good possible improvements. I understand people's concern that the change might make the system more unstable, but using undervolting is a CHOICE. Also if it's done right, it won't make the system more unstable. It will also improve battery life and reduce heat...

To hell with it. If there's no activity soon, i'll take a few versions (kernels for Lucid, and some Maverick alphas), and benchmark them as default or without the modules compiled in (maybe the phc version). Since I only have access to a few machines, I hope others do it also, so we can finally prove if it's bullshit or not to say it's slower.

I also don't understand why if the module is going to be included in the kernel why it cannot have the patch to allow undervolting included. By default it does nothing except show what the current settings are. If you need to undervolt your computer (like I do because it reduces my CPU temperature drastically as I can run it at 0.9V instead of 1.5V) then you can enable it by adding the relevant scripts and settings. It is not likely to cause issues with the average user suddenly breaking their machines because they accidentally undervolted it.

The only solution for me at the moment would be to recompile the whole kernel that takes 4-5 hours or to get a precompiled kernel from someone such ad (ppa:linux-phc/ppa) where I am relying on them not to put a backdoor into my kernel (not that I think they would) and currently they do not compile for Maverick.

This is about allowing us to undervolt to run our machines cooler and not about CPU scaling. My machine already does CPU scaling and that works fine but it still runs hot because the CPU default voltages are way too high.

Please consider adding this small patch to allow undervolting.

Is this going to be marked as declined for Lucid, carried forward to Natty?

I've seen loads of complaints about the move, and no one thanking anyone for it. At least carrying it forward would show it's still on someone's radar. Otherwise close it and mark as won't fix.

Ok.. found some more info from the Kernel Team specs for Natty:

https://wiki.ubuntu.com/KernelTeam/Specs/KernelNattyConfigReview

They have a general policy to build it in because, "it's hard to do in userspace". No idea what that means, or why no other distro has difficulty with building acpi_cpufreq as a module, perhaps something to do with upstart?

In any case, if that's the policy why not just close this mark as won't fix and put an end to it.

If anyone at the Kernel Team reads this, could they please expand on the comment "cpufreq: it's hard to do in userspace"?

If I compile the current kernel myself, with just the one difference in which acpi-cpufreq is a module, everything works perfectly. Just check PPA for linux-phc if you don't believe me.

This would be such a small change with a large impact!

Sure I have old hardware, but I have to recompile the entire kernel with module enabled for speedstep-centrino instead of just compiling the module in a few seconds, as I have to patch the driver for accepting the cpufreq tables for my Sonoma (stepping C0) 2.0 GHz Pentium-M which is not standard built-in (btw also affects all Dothans (stepping B0), only Banyas tables are built-in). BIOS won't enable acpi-cpufreq, of course, supposing it has got all the tables. I guess that this ug is 3 year old and never will be fixed despite solid argumentation and flimsy counter-argumentation.

That canned response doesn't apply, as the problem is not in the kernel itself, but in the configuration Ubuntu is using to compile the kernel.

The fix is simple: in the kernel config, change

CONFIG_X86_POWERNOW_K8=y

and

CONFIG_X86_ACPI_CPUFREQ=y

to

CONFIG_X86_POWERNOW_K8=m

and

CONFIG_X86_ACPI_CPUFREQ=m

respectively.

Confirmed in Trusty Tahr. Boy this guy's been around.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 355232

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Ben A, thank you for you comment. Verified the Trusty configuration as per:
git clone git://kernel.ubuntu.com/ubuntu/ubuntu-trusty.git && cd ubuntu-trusty && grep -r CONFIG_X86_POWERNOW_K8= && grep -r CONFIG_X86_ACPI_CPUFREQ= | grep debian
debian.master/config/config.common.ubuntu:CONFIG_X86_POWERNOW_K8=y
debian.master/config/config.common.ubuntu:CONFIG_X86_ACPI_CPUFREQ=y

As per the Ubuntu maintainer discussion comments (ex. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/355232/comments/15 ) it would seem a strong preference exists not to adjust the defaul config to =m. Would there be a way to achieve undervolt for those who want it in a default install, without modifying the noted configurations or compiling anything (I did notice https://wiki.ubuntu.com/UndervoltingHowto)?

lucid has seen the end of its life and is no longer receiving any updates. Marking the lucid task for this ticket as "Won't Fix".