Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#8500 - PHC undervolt patch in kernel26?

Attached to Project: Arch Linux
Opened by Michal Witkowski (Neuro) - Sunday, 04 November 2007, 10:09 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 20 November 2007, 08:24 GMT
Task Type Feature Request
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Hi.

The only reason I build my own custom kernel is this: https://www.dedigentoo.org/trac/linux-phc/. It allows one to safely undervolt Pentium M > Core 2 Intel chips, saving both battery power and burned laps. I honestly don't care about the Pentium M optimization flags (which I turn on), they don't change a thing. What I do care about is the difference between 72C and 63C under stress (Asus A6JC).

Now, I know it's a feature, but it's a safe one. The patch code doesn't change a thing until the user writes values different from the default ones to appropriate /sys entries.

So if you could please add it to the stock kernel26, it'd be great. Just like DSDT patch it would greatly benefit the laptop users.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Tuesday, 20 November 2007, 08:24 GMT
Reason for closing:  Fixed
Comment by Thomas Bächler (brain0) - Tuesday, 06 November 2007, 17:20 GMT
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.
Comment by Michal Witkowski (Neuro) - Tuesday, 06 November 2007, 19:00 GMT
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.
Comment by Tobias Powalowski (tpowa) - Thursday, 08 November 2007, 16:24 GMT
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.
Comment by Aaron Griffin (phrakture) - Friday, 09 November 2007, 07:29 GMT
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
Comment by Aaron Griffin (phrakture) - Friday, 09 November 2007, 07:48 GMT
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
Comment by Tobias Powalowski (tpowa) - Friday, 09 November 2007, 09:18 GMT
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.

Comment by James Rayner (iphitus) - Friday, 09 November 2007, 14:22 GMT
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
Comment by Thomas Bächler (brain0) - Friday, 09 November 2007, 15:04 GMT
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.
Comment by Aaron Griffin (phrakture) - Friday, 09 November 2007, 17:19 GMT
Quite the controversy you've started Michal 8)
Comment by Michal Witkowski (Neuro) - Friday, 09 November 2007, 18:34 GMT
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.
Comment by James Rayner (iphitus) - Friday, 09 November 2007, 23:57 GMT
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.

Loading...