Also add a comment about the upcoming version 0.2.3. A date is not
stated, as this will be done when the actual release happens (and
I will collect any further patches up to that moment). I expect the
release to be over the next weekend.
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.
