Open GoogleCodeExporter opened 8 years ago
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 42
model name : Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
stepping : 7
microcode : 0x25
cpu MHz : 1600.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
Original comment by ju.leche...@googlemail.com
on 12 Mar 2012 at 12:35
Plain cli works fine.
Downstream report is
https://bugs.gentoo.org/show_bug.cgi?id=407881
Original comment by ju.leche...@googlemail.com
on 12 Mar 2012 at 12:35
Hi Justin
thanks for the report.
looks like optimization flags strike again:
http://code.google.com/p/i7z/issues/detail?id=43
i had to disable two more flags these times, the updated makefile is in the svn
-fno-inline-small-functions and -fno-caller-saves
also it seems that qt4 .pro configuration: if CONFIG = release or if the
optimization flags are other than -O1, GUI doesn't show the C0 states (first
column), but the frequencies are printed correctly.
i am looking into at what is causing this to happen.
Original comment by abhirana
on 12 Mar 2012 at 11:02
#0 Print_Information_Processor (nehalem=0x7fffffffbe48,
sandy_bridge=0xffffbe4c) at ../helper_functions.c:434
This looks like the pointer sandy_bridge was truncated. This may be caused by
the faulty cpuid-Implementation:
static inline void cpuid (unsigned int info, unsigned int *eax, unsigned int
*ebx,
unsigned int *ecx, unsigned int *edx)
{
unsigned int _eax = info, _ebx, _ecx, _edx;
asm volatile ("mov %%ebx, %%edi;" // save ebx (for PIC)
"cpuid;"
"mov %%ebx, %%esi;" // pass to caller
"mov %%edi, %%ebx;" // restore ebx
:"+a" (_eax), "=S" (_ebx), "=c" (_ecx), "=d" (_edx)
: /* inputs: eax is handled above */
:"edi" /* clobbers: we hit edi directly */);
This code will reset the upper half of rbx to zero, but since ebx is not listed
as either output or clobber (and can't with PIC), the compiler won't know about
it. Since rbx must be preserved across function calls, this might lead to the
observed truncation, if the compiler decides to put the pointer into that
register.
Original comment by thetruec...@gmx.net
on 20 Jun 2013 at 1:27
Original issue reported on code.google.com by
ju.leche...@googlemail.com
on 12 Mar 2012 at 12:26