user undervolting

[bdz]

Hello udervolting fellows!

We have just released a new version of the Linux-PHC patch.

Here is the change log:

Code: Select all

0.2.6 - July, 23th 2006: Maintenance release 
    * Support of vanilla kernel version 2.6.18-rc2
    * Support of ubuntu kernel version 2.6.17-5.15 (edgy eft)
    * Added safety code to avoid using invalid operating points on some laptops
    * Documentation update
    * Debug report script enhancement 

You can download it from the sourceforge site: http://sourceforge.net/project/showfile ... _id=161063

We have also setup a new web site. You can visit it here: https://www.dedigentoo.org/trac/linux-phc

One last thing, that may not be very interesting for most readers of this thread:
We are working to add the same sysfs interface to the powernow-k8 driver to undervolt AMD Athlon 64 and Opteron CPUs.
Everybody interested by this new feature can contact us with our mailing list (have a look at the new web site for a link to the linux-phc-user mailing list)

Have a cool undervolting,

BDz

[Mirza]

Code: Select all

patching file arch/i386/kernel/cpu/cpufreq/Kconfig
patching file arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
Hunk #1 FAILED at 11.
Hunk #2 succeeded at 56 (offset 5 lines).
Hunk #4 succeeded at 214 (offset 5 lines).
Hunk #6 succeeded at 566 (offset 5 lines).
Hunk #7 FAILED at 749.
Hunk #8 succeeded at 716 (offset -40 lines).
Hunk #9 FAILED at 745.
Hunk #10 succeeded at 1423 with fuzz 1 (offset -66 lines).
Hunk #11 succeeded at 1505 (offset -53 lines).
3 out of 11 hunks FAILED -- saving rejects to file arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.rej

see? this is 2.6.18 vanilla kernel ... I was using patch from the SVN: linux-phc-0.2.6-kernel-vanilla-2.6.18.patch

M.

[bdz]

Code: Select all

patching file arch/i386/kernel/cpu/cpufreq/Kconfig
patching file arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
Hunk #1 FAILED at 11.
Hunk #2 succeeded at 56 (offset 5 lines).
Hunk #4 succeeded at 214 (offset 5 lines).
Hunk #6 succeeded at 566 (offset 5 lines).
Hunk #7 FAILED at 749.
Hunk #8 succeeded at 716 (offset -40 lines).
Hunk #9 FAILED at 745.
Hunk #10 succeeded at 1423 with fuzz 1 (offset -66 lines).
Hunk #11 succeeded at 1505 (offset -53 lines).
3 out of 11 hunks FAILED -- saving rejects to file arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c.rej

see? this is 2.6.18 vanilla kernel ... I was using patch from the SVN: linux-phc-0.2.6-kernel-vanilla-2.6.18.patch

M.

Can you give the exact version of the kernel you have tried to patch?

linux-phc-0.2.6-kernel-vanilla-2.6.18.patch is based on linux vanilla 2.6.18-rc2
I have tried it on the latest prepatch linux version: vanilla 2.6.18-rc4 and it gave this:

Code: Select all

Applying patch
patching file arch/i386/kernel/cpu/cpufreq/Kconfig
Hunk #2 succeeded at 109 (offset 1 line).
Hunk #3 succeeded at 151 (offset 1 line).
patching file arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c

There was some changes in arch/i386/kernel/cpu/cpufreq/Kconfig between 2.6.18-rc2 and 2.6.18-rc4 but the patch still apply correctly.

BDz

[Mirza]

ooops ... my mistake ... I forgot that I already applied 2 other patches which are little bit conflicting with your patch. sorry.

now is everything ok.

M.

[lxnay]

why not using cpupw ? http://www.tuxamito.com.es/cpupw/index.php

[heilong]

I have a Core Duo (T2400, 2.00GHz), and undervolt prints possible wrong voltages:
"2000000:1404,1667000:1276,1333000:1148,1000000:1004"
A windows utility I'm using for undervolting, RMClock, reports 0.95V as the minimum voltage and 1.2625V as the maximum voltage,
the defaults being 0.95V at 1GHz and 1.2625V at 2GHz.
What is right and what is wrong?

[bdz]

I have a Core Duo (T2400, 2.00GHz), and undervolt prints possible wrong voltages:
"2000000:1404,1667000:1276,1333000:1148,1000000:1004"
A windows utility I'm using for undervolting, RMClock, reports 0.95V as the minimum voltage and 1.2625V as the maximum voltage,
the defaults being 0.95V at 1GHz and 1.2625V at 2GHz.
What is right and what is wrong?

Linux PHC is wrong.

The formula currently used to compute voltage values from VID values is only applicable to Intel Pentium M processors (And maybe some VIA processors).

The current formula is:

Code: Select all

Vcc = 700 + VID * 16

From the voltages you have posted we can computed the VID values that were used by Linux PHC to compute Vcc values:

Code: Select all

2000 MHz: Vcc = 1404 mV -> VID = 44
1667 MHz: Vcc = 1276 mV -> VID = 36
1333 MHz: Vcc = 1148 mV -> VID = 28
1000 MHz: Vcc = 1004 mV -> VID = 19

I'm still not sure of that, but I think that the correct formula for Intel Core processors (not Core 2) is the following:
Vcc = 712.5 + VID * 12.5
(This formula would be valid only for VID between 0 and 63)

From the VID values computed above this would give these Vcc voltages values:

Code: Select all

2000 MHz: VID = 44 -> Vcc = 1262.5 mV
1667 MHz: VID = 36 -> Vcc = 1162.5 mV
1333 MHz: VID = 28 -> Vcc = 1052.5 mV
1000 MHz: VID = 19 -> Vcc = 950.0 mV

BDz

[heilong]

Thanks a lot!
So to fool undervolt to set voltage at 2GHz to 1.0625V, I get it's VID with the 2nd formula: 28, then put it in the 1st formula to get what
linux-phc thinks is the voltage: 1148. Wow, it's cool. Literally, CPU is very cool now ).
Btw, having different /sys/.../cpu0/op_points_table and /sys/.../cpu1/op_points_table didn't look too good to me, so I added
a couple of lines in /etc/conf.d/undervolt & /etc/init.d/undervolt to write the same VTABLE to cpu1/op_points_table. I guess this
will be fixed in some Core Duo (speedstep?) code along with the "CPUs which need to switch frequency at the same time" feature.

[heilong]

Btw, bdz, can you tell me one thing? RMClock under windows can't set voltage on my core duo lower than 0.95V. I'm sure it'll work fine at lower voltages at 1000MHz, for example (coz 0.95V is the default for 1000MHz). linux-phc, on the other hand, allows to echo lower values to the op_points_table. Does it really set the voltage to lower levels or does it just silently ignores the request? Is this a core duo hardware cap, or is it done in software? Can it be overriden in windoze and linux?

[bdz]

Thanks a lot!
So to fool undervolt to set voltage at 2GHz to 1.0625V, I get it's VID with the 2nd formula: 28, then put it in the 1st formula to get what
linux-phc thinks is the voltage: 1148. Wow, it's cool. Literally, CPU is very cool now ).

You are very welcome. It's good to know that this trick is working

Btw, having different /sys/.../cpu0/op_points_table and /sys/.../cpu1/op_points_table didn't look too good to me, so I added
a couple of lines in /etc/conf.d/undervolt & /etc/init.d/undervolt to write the same VTABLE to cpu1/op_points_table. I guess this
will be fixed in some Core Duo (speedstep?) code along with the "CPUs which need to switch frequency at the same time" feature.

I don't know if this feature will solve this problem by itself or if it will require some modifications in the undervolting patch to change the voltages of both CPU at the same time.

And there is another upcoming feature of the Linux kernel that will change a lot of things regarding undervolting: "merge acpi functionality of cpufreq drivers". This feature will remove the ACPI support from the speedstep-centrino driver and merge it into the acpi-cpufreq driver.
As there is no builtin table support for Intel Core processors in speedstep-centrino this means that undervolting these processors with Linux PHC will not be possible anymore.
And people with a Pentium M processor that are using ACPI table will have to switch to built-in table to continue using the undervolting code of speedstep-centrino. (There are good reasons for not wanting to switch to built-in table for Pentium M Dothan processors)

There are solutions for this. One solution would be to add builtin table support for Intel Core processors in speedstep-centrino driver.
Another solution would be to add the undervolting code in the acpi-cpufreq driver.
But I will not be able to implement myself any of these solutions in the near future.

Btw, bdz, can you tell me one thing? RMClock under windows can't set voltage on my core duo lower than 0.95V. I'm sure it'll work fine at lower voltages at 1000MHz, for example (coz 0.95V is the default for 1000MHz). linux-phc, on the other hand, allows to echo lower values to the op_points_table. Does it really set the voltage to lower levels or does it just silently ignores the request? Is this a core duo hardware cap, or is it done in software? Can it be overriden in windoze and linux?

Linux PHC will use the voltages you give to it if they are between 700 mV and the default voltages of the processor.
A while back, while googling around for information about Intel Core processors, I have read some things about about a cap at 0.95 V for the lowest frequency on Intel Core Duo processors. This is one thing about these processors that I've not been able to verify yet. (I dont have any computer with an Intel Core processor)
However if you are able to undervolt your Core Duo with Linux PHC I can tell you how you can verify this yourself:

I have written a small command line utility that reads some information in various place of the computers. I have written it so that people can run it on their computer to help me trying to understand how Core Duo processors are different from Pentium M processors.
Among the gathered information there are the PERF_CONTROL and PERF_STATUS MSR registers. From these registers you can get several frequency and voltage values:

• Min specification frequency and voltage
  Max specification frequency and voltage
  Target frequency and voltage (This is where you will see if Linux PHC takes into account your settings)
  Current frequency and voltage (This is where you should see if the processor takes into account the settings or if there is a cap)

Actually the program outputs the FIDs and the VIDs not the values in Hz and Volts. The interesting part of its output looks like this:

Code: Select all

Detected 2 CPUs

Vendor:	0
Family:	6
Model:	14
Mask:	8
Type:	Intel CORE

CpuFreq info:
  CPU 0: driver = centrino, governor = performance
  CPU 1: driver = centrino, governor = performance

MSR registers:
  CPU 0: PERF_CTL=0x0000000000000a2c, PERF_STATUS=0x06130a2c06000a2c, FSB_FREQ=0x0000000000000133
  CPU 1: PERF_CTL=0x0000000000000a2c, PERF_STATUS=0x06130a2c06000a2c, FSB_FREQ=0x0000000000000133

        |     CPU 0     |     CPU 1     |
        +-------+-------+-------+-------+
        | FID   | VID   | FID   | VID   |
--------+-------+-------+-------+-------+
Min     | 6     | 19    | 6     | 19    |
Max     | 10    | 44    | 10    | 44    |
--------+-------+-------+-------+-------+
Target  | 10    | 44    | 10    | 44    |
Current | 10    | 44    | 10    | 44    |
--------+-------+-------+-------+-------+

In these results:
If you don't have the expected VID in the "Target" line you can tell that the undervolting code has not taken into account your settings.
If you have the same FID and VID for both CPU in the "Target" line and if the VID value is what you have requested but you don't have the same values in the "Current" line you can tell that something is limiting your settings at the processor level.

You can get the source code of this application here: https://www.dedigentoo.org/bdz/linux-phc/
Take the latest msrinfo-X.Y.Z.tar.gz file you find there.

Then you can compile it with something similar to that:

Code: Select all

$ su -
# cd /tmp
# wget https://www.dedigentoo.org/bdz/linux-phc/msrinfo-0.3.5.tar.gz
# tar xzf msrinfo-0.3.5.tar.gz
# cd msrinfo-0.3.5
# ./configure --prefix=/usr
# make && make install

Then you should be able to run the msrinfo program.

Note that you need to be root to be able to run it. You will also need to have the MSR device compiled in your kernel (either builtin or as a module)

Best regards,
BDz

[heilong]

Could use less detail in describing how to compile this )
So, anyway, I've just switched to 1GHz and I can see the "current" VID is only set on CPU0 (at least logically, maybe physically they're synced)
| CPU 0 | CPU 1 |
+-------+-------+-------+-------+
| FID | VID | FID | VID |
--------+-------+-------+-------+-------+
Min | 6 | 19 | 6 | 19 |
Max | 12 | 44 | 12 | 44 |
--------+-------+-------+-------+-------+
Target | 6 | 19 | 12 | 28 |
Current | 12 | 28 | 12 | 28 |
--------+-------+-------+-------+-------+

The min VID of 19, with the 712.5 + VID * 12.5 gives 0.95V. I'll try setting smth lower now.

[heilong]

Yep, setting it to 0.9V (vid=15) didn't work. One side note - when I echo the new VTABLE to the /sys/...op_points_table, my CPU frequence changes from 1GHz to 2GHz. Is this a bug or a feature?
| CPU 0 | CPU 1 |
+-------+-------+-------+-------+
| FID | VID | FID | VID |
--------+-------+-------+-------+-------+
Min | 6 | 19 | 6 | 19 |
Max | 12 | 44 | 12 | 44 |
--------+-------+-------+-------+-------+
Target | 6 | 15 | 6 | 15 |
Current | 6 | 19 | 6 | 19 |
--------+-------+-------+-------+-------+

[bdz]

Yep, setting it to 0.9V (vid=15) didn't work. One side note - when I echo the new VTABLE to the /sys/...op_points_table, my CPU frequence changes from 1GHz to 2GHz. Is this a bug or a feature?

Code: Select all

        |     CPU 0     |     CPU 1     |
        +-------+-------+-------+-------+
        | FID   | VID   | FID   | VID   |
--------+-------+-------+-------+-------+
Min     | 6     | 19    | 6     | 19    |
Max     | 12    | 44    | 12    | 44    |
--------+-------+-------+-------+-------+
Target  | 6     | 15    | 6     | 15    |
Current | 6     | 19    | 6     | 19    |
--------+-------+-------+-------+-------+

Does not look like a feature

What did you echo to /sys/...op_points_table?
Where do you look for frequency to see it change from 1GHz to 2GHz? (The frequency estimation of msrinfo is very likely to be wrong)

From you msrinfo output above the current FID is 6 on both cores. This indicates that the CPU is at 1 GHz. Were you seeing that the CPU was at 2 GHz at the same time you had this output from msrinfo?

Also, seeing the complete output of msr info would be interesting, or at least the part that is before the table.

BDz

[heilong]

I used this:
echo 2000000:1148,1667000:1068,1333000:1004,1000000:940 >/sys/devices/system/cpu/cpu0/cpufreq/op_points_table
Couldn't reproduce switching to 2GHz this time. I'll post if I can.

msrinfo output:
Detected 2 CPUs

Vendor: 0
Family: 6
Model: 14
Mask: 8
Type: Intel CORE

CpuFreq info:
CPU 0: driver = centrino, governor = userspace
CPU 1: driver = centrino, governor = userspace

MSR registers:
CPU 0: PERF_CTL=0x000000000000060f, PERF_STATUS=0x06130c2c06000613, FSB_FREQ=0x0000000000000133
CPU 1: PERF_CTL=0x000000000000060f, PERF_STATUS=0x06130c2c06000613, FSB_FREQ=0x0000000000000133

| CPU 0 | CPU 1 |
+-------+-------+-------+-------+
| FID | VID | FID | VID |
--------+-------+-------+-------+-------+
Min | 6 | 19 | 6 | 19 |
Max | 12 | 44 | 12 | 44 |
--------+-------+-------+-------+-------+
Target | 6 | 15 | 6 | 15 |
Current | 6 | 19 | 6 | 19 |
--------+-------+-------+-------+-------+

Frequency estimations based on TSC:
CPU 0: core = 1995.12 MHz, bus = 332.52 MHz
CPU 1: core = 1995.03 MHz, bus = 332.505 MHz

Frequency estimations based on BogoMIPS from /proc/cpuinfo:
CPU 0: core = 1996.4 MHz, bus = 332.733 MHz, bogomips = 3992.8
CPU 1: core = 1994.73 MHz, bus = 332.456 MHz, bogomips = 3989.47

Frequency estimations based on measured BogoMIPS:
CPU 0: core = 997.293 MHz, bus = 166.215 MHz, bogoratio = 2.0004
CPU 1: core = 997.362 MHz, bus = 166.227 MHz, bogoratio = 2.0004

Frequency estimations based on the FSB_FREQ MSR register:
CPU 0: core = 1000.02 MHz, bus = 166.67 MHz
CPU 1: core = 1000.02 MHz, bus = 166.67 MHz

[albright]

I've undervolting for a year and a half or so on a fujitsu
p7010 (1.1 ghz centrino) without a hitch ... In the last
little while my notebook has been suffering infrequent,
random hard lockups (nothing in the logs AFAIK).

I disabled undervolting and so far no lockups (but more fan )
Is it possible that a chip could *lose* its ability to
undervolt over time?

[heilong]

albright, maybe you just need to blow the dust away from your CPU's heatsink?

[ottuzzi]

Hi there,

I run msrinfo from [1] on my HP nc8430 Core2DUO T7200.
Here are the results:

Code: Select all

Detected 2 CPUs

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

CpuFreq info:
  CPU 0: driver = centrino, governor = powersave
  CPU 1: driver = centrino, governor = powersave

MSR registers:
  CPU 0: PERF_CTL=<failed>, PERF_STATUS=<failed>, FSB_FREQ=<failed>
  CPU 1: PERF_CTL=0x0000000000000613, PERF_STATUS=0x06130c2806000613, FSB_FREQ=0x0000000000000933

        |     CPU 0     |     CPU 1     |
        +-------+-------+-------+-------+
        | FID   | VID   | FID   | VID   |
--------+-------+-------+-------+-------+
Min     | -     | -     | 6     | 19    |
Max     | -     | -     | 12    | 40    |
--------+-------+-------+-------+-------+
Target  | -     | -     | 6     | 19    |
Current | -     | -     | 6     | 19    |
--------+-------+-------+-------+-------+

Frequency estimations based on TSC:
  CPU 0: core = 1994.99 MHz, bus =  failed
  CPU 1: core = 1994.93 MHz, bus = 332.489 MHz

Frequency estimations based on BogoMIPS from /proc/cpuinfo:
  CPU 0: core =  failed, bus =  failed, bogomips = 3995.79
  CPU 1: core = 1995.08 MHz, bus = 332.513 MHz, bogomips = 3990.16

Frequency estimations based on measured BogoMIPS:
  CPU 0: core = 1995.01 MHz, bus =  failed
  CPU 1: core = 997.924 MHz, bus = 166.321 MHz, bogoratio = 1.9992

Frequency estimations based on the FSB_FREQ MSR register:
  CPU 0: core =  failed, bus =  failed
  CPU 1: core = 1000.02 MHz, bus = 166.67 MHz

Please ask for any info you may need!
Bye
Piero

[1]https://www.dedigentoo.org/trac/linux-phc/

[dgaffuri]

And there is another upcoming feature of the Linux kernel that will change a lot of things regarding undervolting: "merge acpi functionality of cpufreq drivers". This feature will remove the ACPI support from the speedstep-centrino driver and merge it into the acpi-cpufreq driver....
Another solution would be to add the undervolting code in the acpi-cpufreq driver.
But I will not be able to implement myself any of these solutions in the near future.

Hi bdz

I've ported a slightly changed old version of your patch to acpi-cpufreq in 2.6.20-rc1, I hope taht this may help you and other users a little. Note that ACPI in speedstep-centrino is deprecated but not yet removed in 2.6.20.

The name of the sysfs entry have been changed to

Code: Select all

/sys/devices/system/cpu/cpu0/cpufreq/cpufreq_freq_voltages

Be aware that this patch is only tested on my 755 CPU and doesn't include any check on the processor type or even the fact that MSR instead of registers I/O is used to switch frequencies, so use at your own risk and only if you really know what you're doing. In other words, don't blame me if you burn your CPU.

Edit: The patch misses a change to correctly check current frequency when voltage is different from default, I will resubmit as soon as I fix it

Code: Select all

--- arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c.save    2006-12-23 14:52:45.000000000 +0100
+++ arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-12-24 13:22:28.000000000 +0100
@@ -69,6 +69,7 @@ struct acpi_cpufreq_data {

 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;

@@ -684,7 +685,7 @@ static int acpi_cpufreq_cpu_init(struct
        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;

@@ -764,6 +765,8 @@ static int acpi_cpufreq_cpu_exit(struct
                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;
@@ -780,8 +783,116 @@ static int acpi_cpufreq_resume(struct cp
        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 & INTEL_MSR_RANGE;
+               voltage = 700 + ((voltage & 0xFF) << 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;
+       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) & 0xFF;
+                       j = data->freq_table[i].index;
+                       if (voltage_index <= (original_acpi_data_control[cpu][j] & 0xFF)) {
+                               control = (original_acpi_data_control[cpu][j] & 0xFFFFFF00) | 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_acpi_data_control[cpu][j] & 0xFF) << 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,
 };

@@ -815,6 +926,8 @@ static void __exit acpi_cpufreq_exit(voi
        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;
 }

[dgaffuri]

Edit: The patch misses a change to correctly check current frequency when voltage is different from default, I will resubmit as soon as I fix it

This one seems to work better, against 2.6.20-rc2. Note also that, unlike in the PHC patch, sysfs node accepts a space separated list of voltages, corresponding to available frequencies.

Code: Select all

--- linux/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c.orig      2006-12-24 18:13:17.000000000 +0100
+++ linux/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c   2006-12-25 17:57:29.000000000 +0100
@@ -57,6 +57,8 @@ enum {
 };

 #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 @@ struct acpi_cpufreq_data {

 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,12 @@ static unsigned extract_msr(u32 msr, str
        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;
@@ -667,7 +671,7 @@ static int acpi_cpufreq_cpu_init(struct
        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;

@@ -747,6 +751,8 @@ static int acpi_cpufreq_cpu_exit(struct
                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;
@@ -763,8 +769,119 @@ static int acpi_cpufreq_resume(struct cp
        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,
 };

@@ -798,6 +915,8 @@ static void __exit acpi_cpufreq_exit(voi
        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;
 }

[Schmolch]

Hey Guys,

i want to try this out, i got the sunrise-overlay and tried to emerge linux-phc with 3 different sources (gentoo, git, vanilla) but i always get this error:

Code: Select all

make[2]: Entering directory `/var/tmp/portage/app-laptop/linux-phc-0.2.8/work/linux-phc-0.2.8/utils/measurefreq/src'
if i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I..     -O2 -march=prescott -pipe -fomit-frame-pointer -MT measurefreq.o -MD -MP -MF ".deps/measurefreq.Tpo" -c -o measurefreq.o measurefreq.cpp; \
        then mv -f ".deps/measurefreq.Tpo" ".deps/measurefreq.Po"; else rm -f ".deps/measurefreq.Tpo"; exit 1; fi
measurefreq.cpp:28:21: Fehler: asm/msr.h: Datei oder Verzeichnis nicht gefunden
measurefreq.cpp: In function »void MeasureFreq(arguments)«:
measurefreq.cpp:196: Fehler: »rdtsc« wurde in diesem Gültigkeitsbereich nicht definiert
make[2]: *** [measurefreq.o] Fehler 1
make[2]: Leaving directory `/var/tmp/portage/app-laptop/linux-phc-0.2.8/work/linux-phc-0.2.8/utils/measurefreq/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/var/tmp/portage/app-laptop/linux-phc-0.2.8/work/linux-phc-0.2.8/utils/measurefreq'
make: *** [all] Fehler 2

!!! ERROR: app-laptop/linux-phc-0.2.8 failed.
Call stack:
  ebuild.sh, line 1613:   Called dyn_compile
  ebuild.sh, line 970:   Called qa_call 'src_compile'
  environment, line 4151:   Called src_compile
  linux-phc-0.2.8.ebuild, line 82:   Called die

!!! emake failed
!!! If you need support, post the topmost build error, and the call stack if relevant.
!!! A complete build log is located at '/var/tmp/portage/app-laptop/linux-phc-0.2.8/temp/build.log'.

Its a fresh Gentoo ~x86 install on a new Laptop (Lenovo X60T).

Sorry if this issue has been discussed a few pages earlier, if not, i never exposed my laziness

[Gentree]

Oh phc!

[rmh3093]

Hey Guys,

i want to try this out, i got the sunrise-overlay and tried to emerge linux-phc with 3 different sources (gentoo, git, vanilla) but i always get this error:

Code: Select all

make[2]: Entering directory `/var/tmp/portage/app-laptop/linux-phc-0.2.8/work/linux-phc-0.2.8/utils/measurefreq/src'
if i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I..     -O2 -march=prescott -pipe -fomit-frame-pointer -MT measurefreq.o -MD -MP -MF ".deps/measurefreq.Tpo" -c -o measurefreq.o measurefreq.cpp; \
        then mv -f ".deps/measurefreq.Tpo" ".deps/measurefreq.Po"; else rm -f ".deps/measurefreq.Tpo"; exit 1; fi
measurefreq.cpp:28:21: Fehler: asm/msr.h: Datei oder Verzeichnis nicht gefunden
measurefreq.cpp: In function »void MeasureFreq(arguments)«:
measurefreq.cpp:196: Fehler: »rdtsc« wurde in diesem Gültigkeitsbereich nicht definiert
make[2]: *** [measurefreq.o] Fehler 1
make[2]: Leaving directory `/var/tmp/portage/app-laptop/linux-phc-0.2.8/work/linux-phc-0.2.8/utils/measurefreq/src'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/var/tmp/portage/app-laptop/linux-phc-0.2.8/work/linux-phc-0.2.8/utils/measurefreq'
make: *** [all] Fehler 2

!!! ERROR: app-laptop/linux-phc-0.2.8 failed.
Call stack:
  ebuild.sh, line 1613:   Called dyn_compile
  ebuild.sh, line 970:   Called qa_call 'src_compile'
  environment, line 4151:   Called src_compile
  linux-phc-0.2.8.ebuild, line 82:   Called die

!!! emake failed
!!! If you need support, post the topmost build error, and the call stack if relevant.
!!! A complete build log is located at '/var/tmp/portage/app-laptop/linux-phc-0.2.8/temp/build.log'.

Its a fresh Gentoo ~x86 install on a new Laptop (Lenovo X60T).

Sorry if this issue has been discussed a few pages earlier, if not, i never exposed my laziness

Try this:

Code: Select all

ebuild /usr/portage/sys-kernel/linux-headers/linux-headers-2.6.20.ebuild compile
cp /var/tmp/portage/sys-kernel/linux-headers-2.6.20/work/gentoo-headers-base-2.6.20/include/asm-i386/msr.h /usr/include/asm/

[Robot_s]

FYI, with a few caveats, linux-pch also works on Yonah (Core Duo) chips.

Most of the caveats are root problems with cpufreq itself - it does NOT handle Core Duo chips well at all. It detects that the two cores are on the same chip (see the affected_cpus value) but still presents independent controls for each CPU. This is WRONG! All frequency/voltage settings are locked for the entire chip (both cores), so having independent settings in cpufreq is nonsensical and often provides inconsistent results.

I've read the datasheet for the Core Duo cpus. It is perfectly correct to set two different frequencies, as the processor chooses the highest one.


Anyways, could someone provide me with some default values for Intel Core Duo T2300? My bios is kinda buggy (since i have reflashed it) and i would like to patch the kernel with some "normal values"

[b3nbranch]

I have a Core Duo (T2400, 2.00GHz), and undervolt prints possible wrong voltages:
"2000000:1404,1667000:1276,1333000:1148,1000000:1004"
A windows utility I'm using for undervolting, RMClock, reports 0.95V as the minimum voltage and 1.2625V as the maximum voltage,
the defaults being 0.95V at 1GHz and 1.2625V at 2GHz.
What is right and what is wrong?

I'm a little confused. Did you have to add a table to speedstep-centrino.c for your T2400,
or did it pick up defaults from somewhere? I would very much like to undervolt my T7400,
and have taken several of the first steps to use PHC, but don't quite understand what you did
to get this far with a processor that's not directly supported by the patch.

Thanks!
Ben

[rafelbev]

I have come across this patch implementing an interesting cpu idle infrastructure. This is being proposed by guys from Intel and should be generic enough for most modern processors. Following some patches on the LKML I believe its first presense inside the git tree is inside the test branch of the acpi git tree. I tried merging it quickly but didn't manage to patch it up well.

It also appears that in current 2.6.21 kernels, most of the speed step stuff has gone out from the speedstep-centrino driver and into acpi-cpufreq driver. I am guessing that the code is now more generic and reusable across the board too. With the latest 2.6.21 and DYNTICKS enabled I managed to scrape another Watt down to 18W. This is still far away from the 11W when booted in Windows