Arch Linux

I am against it. We already have too many patches applied to our "vanilla" kernel, some of them adding features, and I plan on reducing this number.

Furthermore, this is only useful for Pentium M. I checked the homepage a while ago, and it said that for the Core (2), you cannot reduce the voltage below the default voltage at the lowest frequency. If you use cpufreq properly, you will run at that frequency and thus at that voltage most of the time (rendering it useless for Core and Core 2 CPUs).

Introducing an extra patch that has to be maintained and will delay the updates for new kernels even more is not what I want for the -ARCH kernel.

I've got a T2300E Core Duo here. The default voltage for 996MHz (lowest freq) is 1.05V. The lowest possible voltage to set is 0.95V, which works great for 996MHz and 1328MHz (default 1.20V or something like that). The default voltage for 1680MHz (highest freq) is 1.35V which causes the processor to run at 72-74C when under stress (like compiling a big package).

This patch allows me to (safely) undervolt the highest frequency to 1.05V (!!!) reducing the stress temperature to around 63C (below 65C when the fan kicks in). I know that you can achieve even greater undervolts (below 0.8V) with Pentium M processors, but you can't say that the patch is useless for Core (2) processors. In fact it's effect is so important to my laptop that I compile my kernel just for the sake of having it in.

Now, I agree that the vanilla kernel should be free of features. I perfectly understand why you're not so hot about including large patches witch impact many parts of the kernel (like tuxonice or fbsplash). However, this touches a single module, which doesn't change that often between kernel releases and IMHO is worth giving a shot, just like DSDT.

well, this patch doesn't look that bad, it affects only one module to gain sysfs functions.
we only apply fixes to the kernel right now with some feature additions, i don't see a reason in dropping those patches.
the ammount of patches results of lacking kernel devs releasing bugfix versions.

I'm torn. On one hand, it is a rather small patch.

But on the other hand, Thomas brings up the point that it only affects undervolting for Pentium M processors, which seems like that's a small percentage of our users, if I had to guess

If you were to ask me, this is a bit to "edge case", at this point, to put in our main kernel. As it stands, even though it is a small patch, it's wanted by one user (or a very small set of users). If we continually add patches to the kernel because only one user wants them, this will quickly get out of hand

It's not only M processors also those:
Intel Core and Core2 CPUs can be undervolted, but with some limitations. You can not set a lower lower voltage then the lowest standard voltage at the lowest frequency. But it is possible to lower the voltages of higher frequency levels.

it enables you to set the voltages with sysfs, normal systems are not affected at all.


this patch seems unintrusive, applies still to .24 kernel line and might be usefull for people with laptops, who want to get more battery life.
i don't see a reason for deny this patch because at the moment only one person finds it usefull.
i take responsibility for it, as i do with all the other patches applied to the kernel
and i'll revert them immediatly if they break any other users systems.

Don't really agree here.

This patch has no future of being merged to kernel26. Undervolting is running a CPU out of it's specifications, and when done incorrectly can have the same effects on stability as overclocking. Like the kernel devs, do we really want difficult to solve bug reports because some fool ran with innappropriate settings?

This patch has been around for years, and has been rejected on LKML repeatedly. It is not included in any other distro's kernels.

http://lkml.org/lkml/2007/9/4/58
http://lkml.org/lkml/2007/9/3/139

First of all, I find it very impolite that the patch has been added despite the fact that this discussion is not over yet. Furthermore, James, raises two important points: 1) this patch introduces functionality that lets you damage your hardware, 2) it has been rejected on LKML repeatedly. So I am still 100% against merging it.

Quite the controversy you've started Michal 8)

Heh, I always regarded discussion as an important part of projects ;)

Still, the point about it being only usefull for Pentium-M users is not valid. I myself am a user of a Yonah processor, and I find it really really useful. And I think that people with Pentium-M, Core and Core 2 processors aren't such a minority of Arch users after all.

About the damaging your system controversy. The acpi-dsdt patch also isn't in the kernel because the devs said that it can damage the user's system (quote from the faq http://gaugusch.at/kernel.shtml). And just like the DSDT patch, this isn't accessible easily, so that the probability of a "fool" messing up his system is rather low. Especially that the patch will revert the vid table back to it's default values whenever incorrect values are passed through the sysfs interace (the values must exactly match the users CPU allowed voltages), thus making the possibility of setting up one's CPU on fire rather minimal. And just like the DSDT patch it's intended for users who know what they're doing, merely as means of solving one's problems (with wrong ACPI code, or in this case, hot CPU's and battery life). And I always thought that's exactly what Arch is about: providing the user (who knows what he's doing) with the appropriate tools for the task.

Still if the patch won't make it into the kernel, I understand.

Using that as a precedent Neuro, we can put any damaging patch in. See that blue smoke? That _was_ your SATA drives. ;)

We can't use precedent in this area. Each patch needs to be reviewed *independently* and of it's own merits. And then further, re-reviewed each release, which we havn't been doing so much.