user undervolting

Message

b3nbranch · Post by **b3nbranch** » Sun Apr 15, 2007 5:17 pm

I'm still running 2.6.17-11, it sounds like things are advancing on the
power management front in the official kernels, if slowly.

I added a table for my t7400 to the patched speedstep-centrino.c, and
it's working. I'm now fine tuning the voltages. Perhaps this will all get
tossed when I upgrade to 2.6.20 or 2.6.21, but it's been interesting!

rafelbev · Post by **rafelbev** » Mon Apr 16, 2007 10:38 am

Did you manage to get a noticable difference in battery life? Do you have a measurement in watts on the different typical power consumption?

b3nbranch · Post by **b3nbranch** » Mon Apr 16, 2007 1:37 pm

rafelbev wrote:Did you manage to get a noticable difference in battery life? Do you have a measurement in watts on the different typical power consumption?

I'm running an MOTD (Mobile on the Desktop) rig, so no battery. The T7400, just like the
earlier poster's Yonah, seems to be locked at 0.95v@1GHz for the minimum setting, so
no change at idle (56 watts measured by a kill-a-watt meter at the AC outlet). However,
running the Mersenne prime (mprime) torture test at 2.17GHz, the system's power draw
dropped from 98w to 85w, with the CPU running at about 1.02v rather than 1.21v.
The torture test faults quickly at 1.00v; it ran for 3 hours with no problem at 1.01v, and
I'm sticking with 1.02v for a bit of safety margin.

138158 · Post by **138158** » Sun May 13, 2007 12:39 pm

Hi,

why does acpi-cpufreq report other default values then speedstep-centrino?

speedstep-centrino:

798000 -> 988
1064000 -> 1084
1330000 -> 1180
1596000 -> 1276
1862000 -> 1356

acpi-cpufreq:

800000 -> 988
1066000 -> 1068
1333000 -> 1148
1600000 -> 1228
1866000 -> 1308

Thanks for helping.
Best regards,
Whoopie

b3nbranch · Post by **b3nbranch** » Sun May 13, 2007 2:00 pm

Whoopie wrote:Hi,

why does acpi-cpufreq report other default values then speedstep-centrino?
<snip tables>
Best regards,
Whoopie

I haven't completely researched this, but I believe that acpi-cpufreq obtains
tables from the BIOS of the computer, whereas speedstep-centrino uses
compiled-in tables. In fact, I was able to change my frequency steps from
1.0 - 1.33 - 1.67 - 2.17 to 1.0 - 1.5 - 1.83 - 2.17 by editing the appropriate
table in speedstep-centrino.

So the probably cause of the difference is that two difference data sources
are being used.

Hope this helps,
Ben

138158 · Post by **138158** » Sun May 13, 2007 2:20 pm

Hi Ben,

thanks for your answer. It sounds logical.
Just saw that acpi-cpufreq also reports different frequencies:

Code: Select all

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies 
1866000 1600000 1333000 1066000 800000

Best regards,
Whoopie

widan · Post by **widan** » Sun May 13, 2007 4:38 pm

rafelbev wrote:Do you have a measurement in watts on the different typical power consumption?

The ratio of power usages of the CPU only between undervolted and stock should roughly be equal to the square of the ratio of core voltages.

b3nbranch wrote:no change at idle (56 watts measured by a kill-a-watt meter at the AC outlet) ... the system's power draw dropped from 98w to 85w, with the CPU running at about 1.02v rather than 1.21v.

If we assume all the power usage at idle is due to other things than the CPU (not true, the CPU still uses some power at idle, but it's hard to quantify from "wall outlet" measurements), the CPU part of the power usage dropped from 98-56=42 W to 85-56=29 W. Power ratio is 29/42=0.69, and square of voltage ratio is (1.02/1.21)^2=0.71. That's reasonably close to the theory.

info2 · Post by **info2** » Mon May 21, 2007 5:53 pm

Hey,

i have ported dgaffuri's patch to kernel 2.6.22 (ubuntu feisty with gutsy kernel), compiled the acpi_cpufreq.ko and insmod'ed it.
Now i can read the CPU's Voltages:
>>1324 1228 1116 1004
Then i changed the last two values to 1000 and 800, the Patch seems to correct them

, now i have:
>>1324 1228 988 796

I switched the Frequencies around hoping that the kernel will set the new values,
but it seems not to affect something.
The system is as hot as ever even when it is doing (nearly) nothing.
>>Thermal 1: ok, 53.0 degrees C

How can i make sure the system set the Voltages? What could be the problem?

CPU-Info:

Vendor: 0
Family: 6
Model: 15
Mask: 6
Type: Intel CORE2
T7200

Here the Patch-File for 2.6.22:

Code: Select all

--- acpi-cpufreq_orig.c	2007-05-13 20:55:48.000000000 +0200
+++ acpi-cpufreq.c	2007-05-21 15:30:01.000000000 +0200
@@ -57,6 +57,8 @@
 };
 
 #define INTEL_MSR_RANGE		(0xffff)
+#define INTEL_MSR_FREQUENCY    (0xff00)
+#define INTEL_MSR_VOLTAGE      (0x00ff)
 #define CPUID_6_ECX_APERFMPERF_CAPABILITY	(0x1)
 
 struct acpi_cpufreq_data {
@@ -69,6 +71,7 @@
 
 static struct acpi_cpufreq_data *drv_data[NR_CPUS];
 static struct acpi_processor_performance *acpi_perf_data[NR_CPUS];
+static acpi_integer *original_acpi_data_control[NR_CPUS];
 
 static struct cpufreq_driver acpi_cpufreq_driver;
 
@@ -104,11 +107,11 @@
 	int i;
 	struct acpi_processor_performance *perf;
 
-	msr &= INTEL_MSR_RANGE;
+	msr &= INTEL_MSR_FREQUENCY;
 	perf = data->acpi_data;
 
 	for (i=0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
-		if (msr == perf->states[data->freq_table[i].index].status)
+		if (msr == (perf->states[data->freq_table[i].index].status & INTEL_MSR_FREQUENCY))
 			return data->freq_table[i].frequency;
 	}
 	return data->freq_table[0].frequency;
@@ -668,7 +671,7 @@
 	data->max_freq = perf->states[0].core_frequency * 1000;
 	/* table init */
 	for (i=0; i<perf->state_count; i++) {
-		if (i>0 && perf->states[i].core_frequency ==
+		if (i>0 && perf->states[i].core_frequency >=
 		    perf->states[i-1].core_frequency)
 			continue;
 
@@ -749,6 +752,8 @@
 		acpi_processor_unregister_performance(data->acpi_data,
 						      policy->cpu);
 		kfree(data);
+                kfree(original_acpi_data_control[policy->cpu]);
+                original_acpi_data_control[policy->cpu] = NULL;
 	}
 
 	return 0;
@@ -765,8 +770,119 @@
 	return 0;
 }
 
+static ssize_t show_freq_voltages(struct cpufreq_policy *policy, char *buf)
+{
+       struct acpi_cpufreq_data *data = drv_data[policy->cpu];
+       struct acpi_processor_performance *perf;
+       unsigned int i;
+       unsigned int voltage;
+       ssize_t count = 0;
+
+       if (unlikely(data == NULL ||
+            data->acpi_data == NULL || data->freq_table == NULL)) {
+               return -ENODEV;
+       }
+
+       perf = data->acpi_data;
+
+       /* show space separated list of current voltages */
+       for (i = 0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
+               voltage = perf->states[data->freq_table[i].index].control;
+               voltage = 700 + ((voltage & INTEL_MSR_VOLTAGE) << 4);
+               count += sprintf(&buf[count], "%u ", voltage);
+       }
+       count += sprintf(&buf[count], "\n");
+
+       return count;
+}
+
+static ssize_t store_freq_voltages(struct cpufreq_policy *policy, const char *buf, size_t count)
+{
+       unsigned int cpu = policy->cpu;
+       struct acpi_cpufreq_data *data = drv_data[cpu];
+       struct acpi_processor_performance *perf;
+       unsigned int i, j;
+       unsigned int voltage;
+       unsigned int voltage_index, original_index;
+       const char *curr_buf = buf;
+       char *next_buf;
+       acpi_integer control;
+
+       if (unlikely(data == NULL ||
+            data->acpi_data == NULL || data->freq_table == NULL)) {
+               return -ENODEV;
+       }
+
+       perf = data->acpi_data;
+
+
+       /* save original control values to disallow overvolting */
+       if (!original_acpi_data_control[cpu]) {
+               original_acpi_data_control[cpu] = kmalloc(sizeof(acpi_integer) *
+                   perf->state_count, GFP_KERNEL);
+               if (!original_acpi_data_control[cpu]) {
+                       dprintk("failed to allocate memory for old control values\n");
+                       return -ENOMEM;
+               }
+               for (i = 0; i < perf->state_count; i++)
+                       original_acpi_data_control[cpu][i] = perf->states[i].control;
+       }
+
+       /* set new voltages from user space */
+       for (i = 0; data->freq_table[i].frequency != CPUFREQ_TABLE_END; i++) {
+               voltage = simple_strtoul(curr_buf, &next_buf, 10);
+               if (next_buf == curr_buf) {
+                       if ((curr_buf - buf == count - 1) && (*curr_buf == '\n')) {
+                               curr_buf++;
+                               break;
+                       }
+                       dprintk("failed to parse voltage value at %i (%s)\n", i, curr_buf);
+                       return -EINVAL;
+               }
+               if (voltage < 700) {
+                       dprintk("skipping voltage at %i, "
+                               "%u is below the minimum of 700 mV\n", i, voltage);
+               } else {
+                       voltage_index = ((voltage - 700) >> 4) & INTEL_MSR_VOLTAGE;
+                       j = data->freq_table[i].index;
+                       original_index = original_acpi_data_control[cpu][j] &
+                           INTEL_MSR_VOLTAGE;
+                       if (voltage_index <= original_index) {
+                               control = (original_acpi_data_control[cpu][j] &
+                                   INTEL_MSR_FREQUENCY) | voltage_index;
+                               dprintk("setting control %x at %i, default is %x\n",
+                                       (unsigned int) control, i,
+                                       (unsigned int) original_acpi_data_control[cpu][j]);
+                               perf->states[j].control = control;
+                       } else {
+                               dprintk("skipping voltage at %i, "
+                                       "%u is greater than the default %u\n",
+                                       i, voltage,
+                                       700 + (original_index << 4));
+                       }
+               }
+               curr_buf = next_buf;
+               while ((curr_buf - buf < count) && (*curr_buf == ' '))
+                       curr_buf++;
+       }
+
+       /* set new voltage at current frequency */
+       data->resume = 1;
+       acpi_cpufreq_target(policy, get_cur_freq_on_cpu(cpu), CPUFREQ_RELATION_L);
+
+       return curr_buf - buf;
+}
+
+static struct freq_attr cpufreq_freq_attr_freq_voltages =
+{
+       .attr = { .name = "cpufreq_freq_voltages", .mode = 0644, .owner = THIS_MODULE },
+       .show = show_freq_voltages,
+       .store = store_freq_voltages,
+};
+
 static struct freq_attr *acpi_cpufreq_attr[] = {
 	&cpufreq_freq_attr_scaling_available_freqs,
+	&cpufreq_freq_attr_freq_voltages,
 	NULL,
 };
 
@@ -800,6 +916,8 @@
 	for_each_possible_cpu(i) {
 		kfree(acpi_perf_data[i]);
 		acpi_perf_data[i] = NULL;
+		kfree(original_acpi_data_control[i]);
+               original_acpi_data_control[i] = NULL;
 	}
 	return;
 }

info2 · Post by **info2** » Wed May 23, 2007 6:16 am

It seems that the CPU just don't set the new voltages.

checking msrinfo after setting new values shows up new target voltages but they are not reached.

I have no windows on my system (

-> i'm free), but maybe somebody of you have. Could somebody please check if he/she is able to set lower voltages for a Core2 Duo in windows, for example by using " NHC - Notebook Hardware Control " ?

Thank you.

[Update1] :

I asked a friend that owns a T5500 to try NHC and he is able tu set a Voltage of 0.95 @ 1Ghz.
Googling around i found a DataSheed by Intel that says that you can lower the Voltage at lowest speed to 0.750Vcc.
http://developer.intel.com/design/mobil ... 314078.htm

Would be really "hot" if somebody can manage the patch to work. I would be in love with the world if i can make me new Laptop cooler.

brian33x51 · Post by **brian33x51** » Wed Jun 27, 2007 12:33 am

Back to the ORIGINAL question....

Any new utilities to screw with the VRM directly on the fly to change voltages?

I've got this MSI K7D Master-L with 2 thoroughbred athlonmps (well modded xps) which I'm currently running undervolted to 1.45V in the bios.

Normal spec voltage for the cpus (version 681) is 1.6V. My seem to stay ~3C less than before both unloaded and loaded.

I'd like to do some testing without rebooting to see if 1.5V might be cooler, ie if the VRM is overloading from having to supply too many amps.

138158 · Post by **138158** » Wed Jul 11, 2007 7:56 pm

Hi,

there's also https://www.dedigentoo.org/bdz/linux-ph ... re1.tar.gz which adds undervolting support to acpi-cpufreq.

Best regards,
Whoopie

ph03 · Post by **ph03** » Tue Jul 17, 2007 12:40 pm

Whoopie wrote:Hi,

there's also https://www.dedigentoo.org/bdz/linux-ph ... re1.tar.gz which adds undervolting support to acpi-cpufreq.

Best regards,
Whoopie

Would I be able to undervolt AMD Athlon 64 Mobile CPUs using this patched acpi-cpufreq driver?

Regards, ph03

jorrit · Post by **jorrit** » Wed Aug 01, 2007 12:00 pm

pilla wrote:
albright wrote:
AFAIK, cpufreq does both voltage and clock scaling (together)
that's great ... now all I need to find out (why won't somebody
just give me a break and *tell* me) how to control the
voltage *independently* of the clock speed (which is what
I wanted and said I wanted in the first place)

If it can't be done ... well, then it can't be done
I mean... it can't be done. If processors could work reliably with less voltage and the same clock, then I'm sure that the manufactures would release the processors with these settings.

It can be done. I'm doing it because otherwise my AMD would heat up too quickly. The trick is finding out (by experimenting) how low you can go with the voltage without getting an unstable system. I was able to go from 1.45V to about 1.35V with 1800MHz.

Greetings,

info2 · Post by **info2** » Mon Aug 20, 2007 8:36 pm

Hey!

Linux-PHC-0.3 is available now.

You can get it on SF:
http://sourceforge.net/projects/linux-phc/

i'll be also available in the svn on dedigentoo soon.

In this release, all patches are against acpi-cpufreq. The Interface hase changed since 0.2x and now is showing the Voltage ID's (VIDs) instead of voltages.
This Patch has been tested with Pentium-M and Core/Core2 -CPUs. Patches are available for kernel 2.6.20 - 2.6.23. If wished lower versions will be made.

There are some more changes. Take a look at the projects homepage to get them all.

We need more developers and we wish more users that'll give us feedback about averything.

Thank you - and keep cool.

Walldorf2000 · Post by **Walldorf2000** » Tue Aug 21, 2007 9:31 am

I desparetely wait for release 0.4.0 https://www.dedigentoo.org/trac/linux-phc/

0.4.0 - <Released date not defined yet>: Major release ¶
* Add support for the powernow-k8 driver (AMD Athlon 64 and Opteron CPUs)

albright · Post by **albright** » Wed Aug 22, 2007 2:05 pm

anybody know how you modify /etc/conf.d/undervolt and
/etc/init.d/undervolt for the new linux-phc (.3)

the patch worked fine on suspend2-2.6.22-r1 sources, and
I have the new files in /sys .... /cpufreq but I note that
/etc/conf.d/undervolt points to the wrong file now and
/etc/init.d/undervolt won't start (unsurprisingly).

What are the magic words?

TIA

albright · Post by **albright** » Wed Aug 22, 2007 5:23 pm

sorry to add this - I should have put it in my last post:

What is the relation between the VIDS and actual
voltages. With the old linux-phc my chip used these
voltages:

Code: Select all

CUSTOM_VTABLE="1100000:828,1000000:812,900000:780,800000:748,600000:700"

I wonder what VID number corresponds to 8.28v etc?

Ehnvis · Post by **Ehnvis** » Wed Aug 22, 2007 6:39 pm

For Pentium-M: VID = (voltage - 700)/16

For Athlon 64, Turion, Opteron: VID = (1550 - voltage) / 25

voltage in the formulas above has to be in millivolts (ie 828 in your case for the first one).

albright · Post by **albright** » Wed Aug 22, 2007 9:33 pm

thanks ehnvis; it seems to be working. I note that the lowest
possible voltage (700mv) works out to a VID of 0. I guess that's
ok ....

just-linux · Post by **just-linux** » Wed Aug 29, 2007 11:06 am

Is there an ebuild for linux-phc-0.3.0 allready available? I've tried to find one, but to no avail.

Ehnvis · Post by **Ehnvis** » Thu Aug 30, 2007 7:22 am

There is no ebuild for linux-phc you need to grab it from here, https://www.dedigentoo.org/trac/linux-phc/ , and then patch your kernel with it. Not sure if there exists any kernel in portage that already has this patch on it which might be another idea.

just-linux · Post by **just-linux** » Thu Aug 30, 2007 10:55 am

I tried to make one, but unfortunately i failed

It would have been my first ebuild

Anyway, I have now an already patched kernel and everything works fine ( 2.6.22-kamikaze7)

I had a look at the new package and I wonder why there is still the old undervolt config file and the old undervolt init script in the new 0.3.0 version.
And something else, my old undervolt config file looks like:

Code: Select all

# Default voltages that will be restored at shutdown if SWITCH_BACK=yes
DEFAULT_VTABLE="798000:988,1064000:1116,1330000:1244,1596000:1356"

# Custom voltages that will be applied at boot time
CUSTOM_VTABLE="2000000:1164,1600000:956,1333000:876,1066000:796,800000:700"

If i take the formula "VID = (voltage - 700)/16" I would get the 5 VIDs "29 16 11 6 0". But I can't go lower than 18. Why can't I use the voltage 700 (VID 0) as I could before?

Code: Select all

tobi linux # msrinfo

Detected 1 CPU

Vendor: 0
Family: 6
Model:  13
Mask:   8
Type:   Intel Pentium M Dothan C0

CpuFreq info:
  CPU 0: driver = acpi-cpufreq, governor = conservative

MSR registers:
  CPU 0: PERF_CTL=0x0000000000000612, PERF_STATUS=0x06120f2906000612, FSB_FREQ=0x0000000000000311

        |     CPU 0     |     CPU 1     |
        +-------+-------+-------+-------+
        | FID   | VID   | FID   | VID   |
--------+-------+-------+-------+-------+
Min     | 6     | 18    | -     | -     |
Max     | 15    | 41    | -     | -     |
--------+-------+-------+-------+-------+
Target  | 6     | 18    | -     | -     |
Current | 6     | 18    | -     | -     |
--------+-------+-------+-------+-------+

@bdz
Thanks a lot for your small utility! It just works great!

info2 · Post by **info2** » Thu Aug 30, 2007 3:38 pm

Hello,

just-linux, you wondered why there is the old init script? I wonder why you have this old init script. In the final release the gentoo-script is hybrid to take use of the linux-PHC-0.2x interface and the linux-PHC-0.3.0 interface.
Please notice that the release is not in CVS yet but available on sourceforge (mea culpa).
The final release also offers pre-compiled modules for users that don't want to compile the module or the whole kernel.
Take a look at the release notes.

The issue that you can not set a lower vid than 18 sounds not logically to m but i'm interested in what could be the reason.
Other people reported that they could successfully set a VID of 0. Maybe there are other things preventing your system from that? I don't know. Maybe it's because your BIOS is broken. Linux-PHC-0.2x used build-in tables. Linux-PHC-0.3 does not due technically reasons (acpi-cpufreq). There is a new kernel module in developement (named "PHC-EST" initiated by BDZ) that will fix this, but i don't know when it'll be ready.
If somebody of you is interested in helping with the developement of this module - you're welcome.

A look in the future: I found a person that offered us developing a patch for AMD-CPUs, but it'll take some month he said. Stay tuned.

Also the userspace-tool PHCtool is going on in developement. In the upcoming version (0.5) it'll (among many other newfeatures) show voltages next to the VIDs if the cpu (and the matching formula) is known.

If you have questions, you are welcome to meet us in the IRC-Chat. I'm there very often (cmichael), but maybe you need to wait some time until i notice you

I hope i could answear some questions.
see you

info2 · Post by **info2** » Sat Sep 01, 2007 10:15 pm

Some users reported me an error that occurs if they want to read from the interface files.
They get an "No such device".
I tracked town the problem to the point acpi-cpufreq decides either the system is "SYSTEM_IO_CAPABLE" or "SYSTEM_INTEL_MSR_CAPABLE".

Code: Select all

	switch (perf->control_register.space_id) {
	case ACPI_ADR_SPACE_SYSTEM_IO:
		dprintk("SYSTEM IO addr space\n");
		data->cpu_feature = SYSTEM_IO_CAPABLE;
		break;
	case ACPI_ADR_SPACE_FIXED_HARDWARE:
		dprintk("HARDWARE addr space\n");
		if (!check_est_cpu(cpu)) {
			result = -ENODEV;
			goto err_unreg;
		}
		data->cpu_feature = SYSTEM_INTEL_MSR_CAPABLE;
		break;
	default:
		dprintk("Unknown addr space %d\n",
			(u32) (perf->control_register.space_id));
		result = -ENODEV;
		goto err_unreg;
	}

The system of those people that decides to have "SYSTEM_IO_CABALE" while the PHC code check if it's "SYSTEM_INTEL_MSR_CAPABLE".
I think this is caused by broken ACPI BIOS informations.

I'm not sure if this check just can be removed. What do you think?

If this check is neccessary for some reasons, what could be the best way to give ppl with that problem a solution?
Maybe another SysFS file for example, where you can disable this check manually by writing a "1" into it?
I hope you can help since i'm not sure how to solve this at best.

Edit:
just forcing SYSTEM_INTEL_MSR_CAPABLE seems not to work for the user that currently is testing this.

Regards
cmichael

Schmolch · Post by **Schmolch** » Sun Sep 02, 2007 3:16 pm

What are everybody's experiences with undervolting their CPU?
I can't see any difference on my lv core-duo-Laptop regarding heat or battery-life.
l don't see any drop in power-consumption with powertop.
How much does a lower voltage matter on a idle lv CPU?