read_msr output *before* applying any patches

If you have trouble with PHC you can ask and hope for help here.
Post Reply
oOarthurOo
Posts: 14
Joined: Mon 17. Nov 2008, 10:18

read_msr output *before* applying any patches

Post by oOarthurOo » Mon 17. Nov 2008, 10:24

Hi,

I figured the best way to see if the patch would work for my processor would be to run the read_msr tool. So, I downloaded, extracted, made it executable, and ran it. Here is my output:
MSRTOOL V0.1 started...

Displaying data for CPU cpu0
/---------------------------------------
| Current VID: 19
| Current FID: 6
| Target VID: 19
| Target FID: 6
| Highest VID: 44
| Highest FID: 12
| Lowest VID: 19
| Lowest FID: 6
\---------------------------------------

Displaying data for CPU cpu1
/---------------------------------------
| Current VID: 19
| Current FID: 6
| Target VID: 19
| Target FID: 6
| Highest VID: 44
| Highest FID: 12
| Lowest VID: 19
| Lowest FID: 6
\---------------------------------------
What is strange is that I haven't applied any patches. This is a pretty vanilla install of Debian Lenny (soon to be stable!).

Since I've used RMclock on this machine under Windows I'm confident my CPU does support it, and because I've never applied any patches I'm also confident these values are wrong. My concern is that the tool obviously can't be used by me to test whether or not my changes are being applied.

Is there another method, or am I reading this wrong? It appears to me that this output shows I'm already running it as undervolted as possible.

Here is my /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2050 @ 1.60GHz
stepping : 8
cpu MHz : 800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts pni monitor est tm2 xtpr
bogomips : 3196.15
clflush size : 64
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 14
model name : Genuine Intel(R) CPU T2050 @ 1.60GHz
stepping : 8
cpu MHz : 800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx constant_tsc arch_perfmon bts pni monitor est tm2 xtpr
bogomips : 3192.01
clflush size : 64
power management:

Best,
A

the-fallen
Administrator
Posts: 346
Joined: Wed 9. Jul 2008, 19:57

Re: read_msr output *before* applying any patches

Post by the-fallen » Mon 17. Nov 2008, 22:06

Hey and hello Arthur.

Most Intel Core Duo Txxx processors are capable of speed-stepping. I am not sure if your T2050 is not able to but the chance is high it is able to speed-step and to be undervolted.

I do not understand what you mean with the second part. cpuinfo does not give any information about voltages. The only thing there is that your CPU ran @ 800MHz as you read the informations. This means your CPU indeet is capable of speed-stepping and therefor very sure also capable of undervolting.

Just ask if you have more questions.

:)

And Welcome on board

oOarthurOo
Posts: 14
Joined: Mon 17. Nov 2008, 10:18

Re: read_msr output *before* applying any patches

Post by oOarthurOo » Mon 17. Nov 2008, 23:32

Cheers and thanks the-fallen,

I guess my only remaining question is if I read the output of read_msr correctly. It appears to me that read_msr is saying it is already running at it's lowest possible VID. Since I know it is not yet patched, that means that either I am reading the output wrong or the tool is reading the msr values wrong, or a third option I suppose, that my bios is providing bad info to the read_msr tool.

Best,
A

Update: I've since patched and installed the phc enabled module, and updated my kernel to Pentium M from the Debian default of Pentium-Pro, and I've tested to see that it is working by checking:
cat /sys/devices/system/cpu/cpu0/cpufreq/phc_controls
12:44 10:36 8:28 6:19
At this point, since I am already using the lowest possible VID, according to MSR, the only undervolting I could do would be at the higher settings... so I could change my settings to apply, for example:
6:44 6:36 6:28 6:19
Does that sound about right? I'm considering reverting to an older version of my bios to see if the msr tool indicates lower voltages are allowed.

PS. In the course of my researching this subject I stumbled across the fact that cpu info shows my cpu is capable of 8 steps. But available frequencies shows only 4, as indicated by the number of pairs I'm allowed to specify. Leader me to further suspect a bad bios as the culprit. It also makes me wonder if 800MHz is really the lowest "step" for these processors and if that could also be a cause of high heat and constant fan usage.

the-fallen
Administrator
Posts: 346
Joined: Wed 9. Jul 2008, 19:57

Re: read_msr output *before* applying any patches

Post by the-fallen » Wed 19. Nov 2008, 12:12

Heya, now I understand what you mean.

First your CPU is only capable ob 4 Speed Steps. The Information "Stepping" from cpuinfo has something to do with the "version" of your CPU.



The VID 19 is indeed the lowest VID. But this range of VIDs is specified/recommended by the vendor.

As you read the read-msr output the CPU ran @ 800MHz (lowest speed step) and the cpu chose the recommendet VID for that speed step (19). Thats why they were the same.
But if you manually switch to a higher frequency the lowest possible VID and the current VID are not the same.

read_msr reads the >>current<< VIDs from the register but the data can be altered.
Depending on the CPU you can set lower values.
For example with Intel Centrino Mobile CPUs you are able to go below the lowest one.

With your Intel Core CPU you can not set lower VIDs then the lowest default one (it is somehow hardware-fixed so they will not be applied even if you set them) but you can reduce all higher VIDs down to this one.

For example if you have the following VIDs:

33 28 22 19

you could reduce them to

19 19 19 19

So you can not save energy while idling but you can reduce power usage and ->heating !<- on higher frequencies.
Maybe the System is unstable then. You need to figure out how deep you can go.

I have a T7200 with the default VIDs above and can lower them to 22 19 19 19 and being stable with them.

oOarthurOo
Posts: 14
Joined: Mon 17. Nov 2008, 10:18

Re: read_msr output *before* applying any patches

Post by oOarthurOo » Fri 21. Nov 2008, 08:42

You're absolutely correct The Fallen, and thanks for that edifying and cogent explanation. After I changed my governor to performance the read_msr values were indeed much above the lowest. I've since applied some new values and can report great success on a default install of Debian Lenny (2.6.26).

Best,
Arthur

Post Reply