Closed GoogleCodeExporter closed 8 years ago
Hi
could you run the following command in command prompt?
rdmsr 0x198 --decimal
the output of that is the current multiplier. i am not sure why a system msr
gives a wrong multiplier.
its also usually the lowest 16 bits of the returned value which in your case is
3000 which is still incorrect.
Original comment by abhirana
on 11 Jan 2012 at 9:10
rdmsr 0x198 --decimal returns 35210141896704
Original comment by cumulusnimbus@gmail.com
on 12 Jan 2012 at 12:47
CPU is running under different load now so the actual multiplier atm is lower
than the x48 yesterday.
Original comment by cumulusnimbus@gmail.com
on 12 Jan 2012 at 12:48
Hi
i think there is some issue going on with your chip as its not reading the read
only register correctly; the low 16 bits of that register should show the
current multiplier and in your case its showing as 4096 (after converting from
dec to hex to dec)
Original comment by abhirana
on 13 Jan 2012 at 8:14
Well, my CPU works just fine.. :)
You must have missed something in the Intel document specifying this MSR
register.
Can it be that 4096 means (CPU denied OS reading?)
Can you please tell me what document you have found for this Turbo MSR ?
Original comment by cumulusnimbus@gmail.com
on 13 Jan 2012 at 9:08
http://www.intel.com/content/dam/doc/manual/64-ia-32-architectures-software-deve
loper-system-programming-manual-325384.pdf
search for IA32_PERF_STATUS and 198
pg 629 and pg 1641
198H bit 15:0 Current performance State Value
63:16 Reserved.
Original comment by abhirana
on 13 Jan 2012 at 9:59
I will write a small asm stub when i get home and boot it with grub and see
what it says about the MSR. I suspect there is something fishy with the
operation of the CPU in Linux here.
Original comment by cumulusnimbus@gmail.com
on 13 Jan 2012 at 10:17
Hi,
Created a stub booting from bare grub. This code does nothing to initialize any
part of the cpu after grub gives it control. Just issues the rdmsr and prints
the output to screen..
Msr 0x198 is 000027b6'00002200
Msr 0x199 is 00000000'00002200
Msr 0xce is 00001000'70012200
this seems right, 34 normal, 16 minimum and 2200 in current and control msr..?
I can see in last bytes of ce looks like same as the 0x198 in the i7z code
above.. Can there be a code issue?
Original comment by cumulusnimbus@gmail.com
on 15 Jan 2012 at 2:51
cool experiment.
last 16 bits of the register 0x198 and 0x199 are incorrect and 2200 corresponds
to 8704 which is out of range. whereas 0xce has bits 15:8 for the max turbo
mode. 0xce seems to be correct 34 for the max multiplier and 16 from the min
multiplier.
0x198 is readonly and shows the current multiplier, 0x199 is r/w and one can
put any value in it and its upto the proc to accept it or not and then reflect
it within 0x198. i dont know what might happen initially when the machine is
booted, but i am guessing the initial value may be within range and thus 0x198
and 0x199 should reflect values within range.
do you have the same ranges from the tool (not from the ruby script)? it
directly reads from the msr file rather than via rdmsr. the other idea is to
use windows and see if you get the same results.
Original comment by abhirana
on 16 Jan 2012 at 6:50
Hi
i was wrong. the documentation is wrong and they shifted the bits without
noting it down.
on a 2600k and 2720QM, it seems that on sandy bridges bits 15:8 show the
correct bios multiplier. so the 2200 (15:8 are 22 and in hex = 34x multiplier)
and in the first post the (15:8 bits are 30 and in hex = 48x multiplier)
thanks
Original comment by abhirana
on 9 Mar 2012 at 1:17
Original comment by abhirana
on 31 Mar 2012 at 8:35
Original issue reported on code.google.com by
cumulusnimbus@gmail.com
on 11 Jan 2012 at 5:46