Open GoogleCodeExporter opened 8 years ago
What steps will reproduce the problem?
1. OC Sandy Bridge system
=> With OC I mean overclocked.
Original comment by getag...@web.de
on 5 Mar 2011 at 4:30
thanks a lot for the bug report. its high on my todo list.
i am guessing intel has changed how it puts the max turbo value in the
register. i will take a look at the latest doc and update.
Original comment by abhirana
on 6 Mar 2011 at 10:08
Not working for Version 0.27 (2/Aug/11) and the SVN version.
I still get the wrong output.
Original comment by getag...@web.de
on 3 Aug 2011 at 5:04
hi
will it be possible to see if turbostat
(http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/turbostat
/turbostat.c , you will need to compile using gcc -o turbostat turbostat.c and
then ./turbostat)gives the same results or different? we could find out if its
a problem with the tool or something else
also what multipliers and bclk freq are reported in windows?
the one other thing i can think of is disabling cpufreq via modprobe -r cpufreq
maybe thats limiting your top frequency.
regards
Original comment by abhirana
on 3 Aug 2011 at 5:20
I had the same problem (and also the same CPU). The real reason was that my
installation of Linux didn't trigger the turbo, even when the same installation
worked on the first generation of i7's.
I got it working by loading acpi_cpufreq module. Now I can see that i7z (SVN
r56) displays turbo correctly for Sandy Bridge CPUs.
Original comment by 00j...@gmail.com
on 5 Aug 2011 at 4:51
Gee, loading acpi_cpufreq module did the trick, thanks!
Original comment by getag...@web.de
on 19 Aug 2011 at 7:47
I have an i5 2500K and the i7z program reads the turbo multiplier correctly.
Unfortunately, when I run handbrake, the speeds and multipliers increase then
they read as "Garbage." Why would this program affect the output in this way?
J
Original comment by piconew...@gmail.com
on 4 Sep 2011 at 1:05
@piconew...
the issue i had once was that the sum total of residency in various C states is
equal to 100 but not always so due to the fact that i dont read it all values
at once and it may happen that due to some jitter that sum increased or
decreased from what is expected.
What i did then was change the code so that if the sum total is >100% it will
say garbage results. but this doesnot always work in all cases like
overclocking or under duress (like due to load the time counters are read a bit
later, etc. i personally seen it sometimes happen when the cores are initially
loaded and the scheduler pushes i7z down in priority.
i check this range via a macro in i7z.h at line 163
http://code.google.com/p/i7z/source/browse/trunk/i7z.h#163
i.e. i check whether the range is between 0-105% and only print it then. right
now i have set it to 105, change it to a larger number.
#define IS_THIS_BETWEEN_0_100(cond) (cond>=-1 && cond <=105 && !isinf(cond) &&
!isnan(cond))? 1: 0
change the upper limit to 125
#define IS_THIS_BETWEEN_0_100(cond) (cond>=-1 && cond <=125 && !isinf(cond) &&
!isnan(cond))? 1: 0
and this should hopefully fix the garbage values
Original comment by abhirana
on 6 Sep 2011 at 2:31
Original issue reported on code.google.com by
getag...@web.de
on 5 Mar 2011 at 4:29Attachments: