# Incredibly strange power managment behavior on I7

## Ormaaj

The short version: Cpufreq either doesn't work, or cannot adjust the clock speed. Also frequencies aren't reported to linux correctly. The rest of this thread basically describes how things break differently in any configuration I can come up with. Note I referred to "cpu frequency ratio" as "multiplier" in this post.

The behavior of nearly every aspect of cpufreq, and the Intel power management and clock-setting features on Nehelem are completely nonsensical - to the point that I have no idea what frequency my computer is actually operating at, and no idea why it acts certain ways under certain conditions. I'm on an I7 920 and an Asus rampage II extreme mobo. Since I have no clue whats going on, I'll just explain what happens:

No linux tool (/proc, dmidecode, conky, x86info, hwinfo, powertop, cpufreq-info) takes into account bclk frequency in calculating cpu frequency. The best I can do is use lmbench's mhz to estimate frequency, and this will only measure what I assume to be the first core's speed. This is apparently mentioned on the kernel mailing list, and I get the impression that there is no plan to fix this problem.

The bios for some reason has an explicit 21st multiplier option available for the i7 920, and apparently (according to both the frequency I'm getting from lmbench, and the frequency reported by the bios at boot-time) it actually works. From everything I have read, this shouldn't even be possible because 21x and 22x are supposed to be only settable by the processor itself when the criteria for turbo-boost are met. This setting is completely undocumented from what I can tell.

When setting the multiplier to 21 with c-states, TM, C1E, and power limit disabled, the multi is always 21, never going to 22, as if there is really a 21st multi option, and the processor never goes to 22 on a single core as it should if turbo-boost were really what was causing 21x. The bios in this case reports back the frequency correctly as 21 at boot time. Cpufreq fails to load entirely, with cpufreq-info showing no frequency scaling driver loaded. Linux does in this case count bclk in calculating frequency, but returns the frequency as though the multiplier were 20 instead of 21.

When setting the multiplier to auto with c-states, TM, C1E, and power limit disabled, the multiplier appears to always be at 21, never going to 22, as above. The bios in this case incorrectly reports the frequency as though it were 20x at boot time. Cpufreq appears to load, and appears as though it is adjusting frequency dynamically with the ondemand and conservative scaling drivers. However, lmbench, and my temps indicate that it is actually having no effect, and clock frequency remains unchanged. Linux reports the frequency not counting either bclk or turboboost, with a frequency of the stock clock speed at most.

When setting the multiplier to anything from 15-20, behavior is the same as above, except the actual frequency never goes above what is set in the bios. The bios reports the correct frequency at boot-time, the cpufreq driver loads and appears to work, yet does nothing, and the kernel reports the frequency not counting bclk.

When setting the multiplier to either auto or 21 with c-states enabled, behavior is identical to the respective cases above, except now according to lmbench, the actual frequency is at 22x (on at least one core, impossible to tell for sure). The bios still incorrectly returns the frequency as though it were set to 20x. The kernel reports frequency as 20x either counting or not counting bclk depending on whether multi is 21 or auto.

There are still no linux drivers for the I2C hardware monitoring chip for this board yet - even in 2.6.30-RC.

There is no way of interfacing with any of the board-specific features for adjusting voltage, frequency, and other bios settings from userspace, though it should be theoretically possible since asus includes proprietary windows-only drivers for doing this.

Tested kernels 2.6.28 to 2.6.30-x.

----------

## mgrela

Are you using cpufreq-acpi driver or the speedstep driver in the kernel ?

Have you tried to report these problems on the kernel bugzilla ?

 I'm afraid they are to kernel-specific for anyone on this forum to give you the answers you are seeking.

----------

## Ormaaj

 *mgrela wrote:*   

> Are you using cpufreq-acpi driver or the speedstep driver in the kernel ?
> 
> Have you tried to report these problems on the kernel bugzilla ?
> 
>  I'm afraid they are to kernel-specific for anyone on this forum to give you the answers you are seeking.

  Using cpufreq-acpi. It is pretty clear from the documentation that speedstep is depreciated and at this point only useful for pentium 4 and below. Maybe I will try it and see what happens because the bios actually lists c-states and speedstep as separately configurable options. Even so, according to the docs, cpufreq-acpi implements speedstep for newer chips.

I don't have a clear understanding of how all of the processor and motherboard features interact, and I'm not sure If anybody really knows for sure. From what I gather, There are P-states (power/performance?), C-states (has something to do with frequency scaling, adjusting voltages dynamically, and idling individual cores), and S-states (sleep states) - in addition to speedstep, and "turboboost". Related to turboboost, there are also several "Features" for "Protecting" the processor in addition to the multiplier lock, which scale processor frequency and voltage, as well as adjust the multiplier without any input from either the bios or the kernel. Nehalem is designed such that even the BIOS doesn't fully have control over what the processor does. Motherboard manufacturers implement various "tricks" to get the processor to ignore some of these which afaik are undocumented and probably break things.

Most of the info out there deals with how these things are supposed to behave on a high level and the expected behavior when running on windows along with proprietary mobo driver software.

Maybe i'll try lkml. I'm way to ignorant to post a bug thats of any use to anyone. As I said also, I get the impression all of this shifty Intel and motherboard manufactuer (mis)functionality grossly violates the ACPI specification and I'm afraid all of this nonsense will result in a "wontfix".   :Crying or Very sad: 

----------

## Chewi

I don't know if you ever found the answer but I've been a little confused by the cpufreq situation on my new i7-875K. The ACPI P-states driver that I used to use on my Core 2 doesn't seem to work anymore. From what little I can gather, it has been rendered obsolete by the CPU's own Turbo Mode. You can use i7z to see what's actually going on here.

----------

## s4e8

That's the way turbo boost work. The CPU rated at 20x, but with turbo boost on, it always running above 20x. There's a P-state above rated multiplier, that's turbo boost state. If you or cpufreq set multiplier below rated multiplier, turbo boost is disabled. If the P-state is the one above rated, the cpu will up multiplier depend on active cores and temperature, etc. The cores support 4 c-state: C0(running), C1(idle), C3 and C6(sleep), only C3 & C6 counted as inactive core. If you disable C-state (C3 and C6), 4 cores will always active, and no more 22x (single core active).

----------

