Failure during cpuid query to function 0x80000001

[GoogleCodeExporter]

On some systems, expecially Brazos and some rare K10s, has been reported from 
some users a failure during a query on cpuid function 0x80000001. This leads to 
program malfunction since it will grab invalid details from the processor.
The program became completely useless since it can't retrieve the correct 
number of cores, nodes and cpu type.

A typical output is like this:

Turion Power States Optimization and Control - by blackshard - v0.422

cpuid:pread: Invalid argument
Brazos::Brazos - Fatal error during querying for Cpuid(0x80000001) instruction.
Wrong node. Allowed range: 0--1
Wrong core. Allowed range: 0--1
Main processor is 
    Family: 0x0     Model: 0x0      Stepping: 0x0
    Extended Family: 0x0    Extended Model: 0x0
    Package Type: 0x0   BrandId: 0x0    
Machine has 0 nodes
Processor has 0 cores
Processor has 0 p-states
Processor has 0 boost states

Power States table:

Done.

The cause is not yet known, but yet it has been reported only on Linux 
platforms and can't be sure that it is a cpuid kernel module malfunctioning.

Original issue reported on code.google.com by paolo.sa...@gmail.com on 20 Mar 2012 at 4:12

[GoogleCodeExporter]

I get this error when I try to use a 32-bit build of the tool. The problem 
seems to be missing Large File Support which prevents it from seeking past 
0x7fffffff.

Adding LFS CFLAGS in the Makefile like this seems to fix the problem:
PROJ_CXXFLAGS=-O2 $(CXXFLAGS) $(shell getconf LFS_CFLAGS)

Original comment by lichv...@gmail.com on 16 Jun 2012 at 12:08

[GoogleCodeExporter]

Hello lichvarm, I implemented the compiler flag you suggested and uploaded the 
code in main trunk.
I'll ask some people if they get the problem solved and as soon as possibile 
I'll repackage the whole thing for a new version.

Original comment by paolo.sa...@gmail.com on 16 Jun 2012 at 1:21

• Changed state: Started

[GoogleCodeExporter]

Other users were identifying the same issue;

I am not certain if this is useful, for the Interlagos branch, I was required 
to change any reference to "getBits" with "getBitsLow" (and "getBitsHigh" if 
the upper bits were required)

If the original user is able to contact me, I can update the Brazos code for 
them to test prior to committing it.

Original comment by gj_b...@yahoo.ca on 4 Jul 2012 at 7:37

[GoogleCodeExporter]

Mmmh, I don't see the point to change getBits to getBitsLow/High. GetBits is 
supposed to retrieve the whole 64 bit MSR back, getBitsLow/High instead will 
return just the lower part (32 bit EAX register) and higher part (32 bit EDX 
register).

Can you be more detailed about the request you received? It doesn't look to 
deal with the problem described in this issue too, and it should be solved 
itself with the patch to the makefile described in comment #1

Original comment by paolo.sa...@gmail.com on 4 Jul 2012 at 10:05

[GoogleCodeExporter]

The LFS looks like it may solve the issue, apologies for the confusion.

The user was running a 32 bit OS, which had an issue returning the 64 bit MSR 
correctly.  It may have been caused by the missing Large File Support, I 
wouldn't have related the return of the MSR with Large File Support.

Disregard the workaround.

Original comment by gj_b...@yahoo.ca on 8 Jul 2012 at 12:32

[GoogleCodeExporter]

Hi,
the updated makefile fixed the problem for me. 
Thanks a lot!

Original comment by steve...@gmx.net on 19 Oct 2012 at 4:38

[GoogleCodeExporter]

[doing some housekeeping here -- fixed and verified]

Original comment by kszy...@gmail.com on 10 Dec 2012 at 8:39

• Changed state: Verified