error: ‘MSR_NHM_TURBO_RATIO_LIMIT’ undeclared about corefreq HOT 16 CLOSED

Hello,
Do you have linux-headers package installed ?
Because MSR_NHM_TURBO_RATIO_LIMIT is defined into /usr/include/asm/msr-index.h which is a header file included in this package.

from corefreq.

Hey,
I have the same problem building the module on Arch (though not from AUR).
I do have /usr/include/asm/msr-index.h and there's MSR_NHM_TURBO_RATIO_LIMIT in it.

from corefreq.

I figured it out, the problem is the custom kernel i use (linux-pf). For some reason, the module builds only with stock Arch kernel.

from corefreq.

Hm, seems like the custom kernel is not the issue :)
I installed the Arch stock kernel of version 4.8.2 from testing and the build fails.
So i think the actual reason is the kernel version.

from corefreq.

Thanks for your return 💯

I have also noticed that you are using a testing version 4.8 of the kernel (as JodiTheTigger's log) whereas I'm compiling with the current version 4.7.6-1 for ArchLinux.

Meanwhile I also found that 2 packages provide the msr definition:

1. linux-api-headers (/usr/include/asm/msr-index.h)
2. linux-headers /usr/lib/modules/4.7.6-1-ARCH/build/arch/x86/include/asm/msr-index.h)
   (any diff however between these 2 files).

If you want to stick with the testing kernel, I suggest you to copy/write the few missing definitions into the CoreFreq header file 'intelmsr.h' , such as:

#define MSR_NHM_TURBO_RATIO_LIMIT 0x000001ad

from corefreq.

JFYI i found the following patch: https://patchwork.kernel.org/patch/9217367/ .
Seems like MSR_TURBO_RATIO_LIMIT should be used now, what do you think?

from corefreq.

Indeed, they are duplicated.
So, I have push an updated corefreqk.c to handle this change.
I also test the case (lines #889) that it will style build with previous kernel versions.

from corefreq.

Great, thanks :)

from corefreq.

Btw, I just few CPU to test CoreFreq with (Bloomfield, Core 2 duo T7250, AMD Turion)
I will appreciate if you can post in reply screenshots of corefreq-cli monitoring your processor(s).
That will be a great help.

from corefreq.

Sure.
I also loaded one core with CPU-bounded task.

from corefreq.

CoreFreq is running a Haswell, Thank you very much 👍

My 2 ways to reach the max turbo on 1 core:
sol 1. in BIOS, limit your settings to one core only activated
sol 2. disable all cores beside #0 using command
echo 0 > /sys/devices/system/cpu/cpu1/online
echo 0 > /sys/devices/system/cpu/cpu2/online
...
echo 0 > /sys/devices/system/cpu/cpu7/online

solution 2 is easier and CoreFreq is cpu hot-plug aware; thus you can disable/enable as wishes.

Prerequisites:
1- 'intel_idle' is your actual Linux cpudriver
--> you can check it by restarting corefreqk.ko module with the option IdleDriverQuery=1
--> next, in corefreq-cli the cpu driver will be printed beside the Linux version

2- Blacklist the module nmi_watchdog (which consumes permanently one fixed state counter)
--> In your kernel boot argument, you can add: nmi_watchdog=0

3- Decrease the sleep interval of corefreqk to its minimum of 500 ms
--> use the option SleepInterval=500 when starting module
This should provide an almost real time monitoring of the cores.

from corefreq.

I don't need max turbo on one core :)
I just ran it so there would be some activity on the screenshot other than just 0-1% jitter.
Anyway, thanks for the tips!

from corefreq.

from corefreq.

Ok, so I tried the AUR package again, and it all works! Thanks!

from corefreq.

@ JodiTheTigger: Thank you for your screenshot, but I can see some layout issues.

• red turbo bars going out of the view
• footer line is repeated 3 times
  Do you confirm these layout issues ?

from corefreq.

Running it in under fish using konsole under gnome3 on arch linux.

yes, I consistently get both issues.

from corefreq.