rdmsr.c:616:10: warning: comparison of 0 <= unsigned expression is always true [-Wtautological-compare]
if(0 <= val && val <= 7) { // Support 8 P-states
~ ^ ~~~
rdmsr.c:572:8: warning: variable 'val' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if(!multiplier)
^~~~~~~~~~~
rdmsr.c:574:8: note: uninitialized use occurs here
if(val > 0) {
^~~
rdmsr.c:572:5: note: remove the 'if' if its condition is always true
if(!multiplier)
^~~~~~~~~~~~~~~
rdmsr.c:541:14: note: initialize the variable 'val' to silence this warning
uint64_t val;
^
= 0
2 warnings generated.
Tested on GhostBSD (based on FreeBSD)
It should work on DragonFlyBSD (the cpuctl driver has been ported from FreeBSD)
The situation for OpenBSD and NetBSD is not clear ; not supported
The detected intel brand code and model code (arbitrary numbers,
related to the detection algorithm) are printed at verbosiness level
2 or higher. You can see them with `cpuid_tool --all -vv` (if running
on an Intel CPU), or, generally, when decoding Intel CPU data, e.g.
`cpuid_tool --load=tests/intel/nehalem/bloomfield.test --all -vv`.
According to wikipedia, cpu-world and some cpu-z screenshots, these processors
do have a code name and it's willamette, northwood, prescott or cedar mill
Signed-off-by: Veselin Georgiev <anrieff@gmail.com>
The reason was that the invocation of the cpuid_tool through the makefile
was using LD_LIBRARY_PATH=. to force link&use of the latest-build libcpuid
library. This doesn't seem to work, so using LD_PRELOAD to explicitly load
libcpuid.so into cpuid_tool.
The committed approach of course doesn't work on Mac OS X, where
make test-old should be used.
msrdriver.c was forgotten from Makefile.am, under the assumption that
autotools are used under *nix only. This is not true, as one could use
MinGW or cygwin.
The reason for the apparent slowness was that the "cpuid_tool" that
was being called from run_tests.py is actually a shell script - a
wrapper, installed by libtool. The script was heavy enough to cause
substantial overhead. Just bypassing it (by using the real
cpuid_tool binary) reduced "make test" running time from 4.1 to 0.7s
on my machine.
It is a bit hacky, though, so "make test-old" is retained, which
uses the old invocation.
On Windows, we don't have the API that Linux provides, which can be used
to query MSRs of particular CPU cores. However, the same behaviour can be
emulated. Say that the driver handle object also stores 'dedicated thread
index'. When you call 'cpu_msr_driver_open()', this index is set to -1,
so further API functions do not force which core should be executing
RDMSR code. I.e. "I don't care on which core I run".
However, if this is non-negative number, the subsequent
functions like cpu_rdmsr() are forced to pass through this core by
using temporary affinity mask.
