DSDT for Asus P8P67-M PRO

[flAked]

Check out the thread at tonymac, we have some reports!

[Time2Retire]

Check out the thread at tonymac, we have some reports!

Good news, but nothing earth shocking. I also fail to detect actual CPU stepping. Tool doesn't work or... we knew this all along?

 

I do see that the max to be included C-State is C7 (what Apple has). For us that is C-6.

 

Wow. User g1011999 is in need of a better cooler or check the voltage - i5-2500K running at 69 degrees centigrade (98 - 29 = 69).

 

There are a few things that I want to check. The first one being the latency in APSS - the higher the latency the longer the CPU stays in a certain P-State. This should help us detect if the CPU stepper actually works or not.

[flAked]

I found something. Calling rdmsr(0x198) globally will return TurboMode multipliers, where per_cpu rdmsr will not.

 

There are a few things that I want to check. The first one being the latency in APSS - the higher the latency the longer the CPU stays in a certain P-State. This should help us detect if the CPU stepper actually works or not.

Bump up the latency for the lowest state, so on running a benchmark it will rise slower?

 

Just read bits 16-22 of MSR 0x1A2 and 0x19C – the actually temperature is the value you get by reading 0x1a2 minus the value returned by 0x19c.

bitfield32(msr, 16, 6)

 

Is that correct?

[Time2Retire]

You want: bitfield32(msr, 22, 16);

[flAked]

I solved the mystery:

 

IA32_PERF_STATUS is a package MSR on SandyBridge, therefor calling it on all processor results in the same value.

 

MSR_TEMPERATURE_TARGET is a unique MSR.

 

 

May 25 23:35:21 slave kernel[0]: MSRDumper:   39   39 42 41 
May 25 23:35:21 slave kernel[0]: MSRDumper: multiplier: 16
May 25 23:35:26 slave kernel[0]: MSRDumper:	3939  3942   
May 25 23:35:26 slave kernel[0]: MSRDumper: multiplier: 26
May 25 23:35:31 slave kernel[0]: MSRDumper:   40  37 39  42 
May 25 23:35:31 slave kernel[0]: MSRDumper: multiplier: 16
May 25 23:35:36 slave kernel[0]: MSRDumper:	53 45  46 41 
May 25 23:35:36 slave kernel[0]: MSRDumper: multiplier: 36
May 25 23:35:41 slave kernel[0]: MSRDumper:	52 51 50  56 
May 25 23:35:41 slave kernel[0]: MSRDumper: multiplier: 34
May 25 23:35:46 slave kernel[0]: MSRDumper:	45 45 45  46 
May 25 23:35:46 slave kernel[0]: MSRDumper: multiplier: 37
May 25 23:35:51 slave kernel[0]: MSRDumper:	443  2 42 42 
May 25 23:35:51 slave kernel[0]: MSRDumper: multiplier: 16
May 25 23:35:56 slave kernel[0]: MSRDumper:	 45 46 43 40 
May 25 23:35:56 slave kernel[0]: MSRDumper: multiplier: 35
May 25 23:36:01 slave kernel[0]: MSRDumper:	 44 42 51 49 
May 25 23:36:01 slave kernel[0]: MSRDumper: multiplier: 35
May 25 23:36:06 slave kernel[0]: MSRDumper:	 51 41 48 46 
May 25 23:36:06 slave kernel[0]: MSRDumper: multiplier: 35
May 25 23:36:11 slave kernel[0]: MSRDumper:	 451 42 51 6 
May 25 23:36:11 slave kernel[0]: MSRDumper: multiplier: 34
May 25 23:36:16 slave kernel[0]: MSRDumper:   40 42   41 43 
May 25 23:36:16 slave kernel[0]: MSRDumper: multiplier: 22
May 25 23:36:21 slave kernel[0]: MSRDumper:   40   44 39 38 
May 25 23:36:21 slave kernel[0]: MSRDumper: multiplier: 16
May 25 23:36:26 slave kernel[0]: MSRDumper:	41 4142   42

[Time2Retire]

I solved the mystery:

 

IA32_PERF_STATUS is a package MSR on SandyBridge, therefor calling it on all processor results in the same value.

 

MSR_TEMPERATURE_TARGET is a unique MSR.

So what's the output now?

 

You can also read: MSR IA32_APERF (0xE8) and MSR IA32_MPERF (0xE7) to get the load ratio (IA32_APERF/IA32_MPERF) of hardware coordinated P-States!

 

What is Asus is exposing the P-States as hardware coordinated? Read this:

 

"If P-states are exposed by the BIOS as hardware coordinated, software is expected to confirm processor support for P-state hardware coordination feedback and use the feedback mechanism to make P-state decisions."

 

And that feedback mechanism is the above calculation. We also know that AICPUPM is actually reading these MSR's so I think that if you see different load values, that we are on track!

[flAked]

You can also read: MSR IA32_APERF (0xE8) and MSR IA32_MPERF (0xE7) to get the load ratio (IA32_APERF/IA32_MPERF) of hardware coordinated P-States!

Yeah, had that already in there, but gave me a KP, need to do more value-checking. It's a bit more complex, one needs to measure the performance over time and factor that in the current percentage formula. One also needs to clear the PERF-registers. Too tired to do that funky stuff

 

See above for the temp-results.

[Time2Retire]

Yeah, had that already in there, but gave me a KP, need to do more value-checking.

CPUID.06H.ECX[bit 0] must be 1 and I assume that EIST / C1E must be enabled in the BIOS.

 

See above for the temp-results.

Perfect. We are getting somewhere, be it slowly LOL

 

p.s. Both registers are reset at the same time so there is no need to measure it over a certain period. We are not writing a PM software driver. Just a reporter.

[flAked]

I made a quick confirmation test, running prime95 benchmark on 4 threads for 2 minutes.

 

Both Windows 7 and OSX stay in the temperature range of 38° - 58° C

[Time2Retire]

I made a quick confirmation test, running prime95 benchmark on 4 threads for 2 minutes.

 

Both Windows 7 and OSX stay in the temperature range of 38° - 58° C

Great. I can't confirm it because the values are all mixed up. Like it is too quick or something. Or too slow. Whatever.

[flAked]

Try setting it to 2000 ticks in the event-function.

[Time2Retire]

Try setting it to 2000 ticks in the event-function.

I am changing it a bit. We only want (need) to read MSR_TEMPERATURE_TARGET at startup. Also. You are suposted to check bit-31 of IA32_THERM_STATUS before using it. This to see if you can read the temperature. If the data is valid.

 

I also want to buffer the data because IOLog is rather slow.

[flAked]

Sounds good, hadn't had the time to do it properly. I was working on a IOUserClient interface to read the data from a kext, so I left MSRDumper in it's hackish way. It's a lot of work though, so I prioritized

[Time2Retire]

Sounds good, hadn't had the time to do it properly. I was working on a IOUserClient interface to read the data from a kext, so I left MSRDumper in it's hackish way. It's a lot of work though, so I prioritized

No problem. Buffering works now. Busy updating it further. And to give you an idea of what I did:

extern "C" void getTemp(void *arg)
{
UInt64 msr = rdmsr64(IA32_THERM_STATUS);

if (msr & 0x80000000)
{
	UInt32 logicalCoreNumber = cpu_number();

	gCoreTemperatures[ logicalCoreNumber ] = (gMaxCoreTemperature - bitfield32(msr, 22, 16));
}
}

Then I loop over it and this is what I get (example):

 

MSRDumper(@16) CoreTemps: 26 36 33 30

 

Now going after load values...

 

Q: How do you print a degree sign? That is if IOLog can do that...

[flAked]

Q: How do you print a degree sign? That is if IOLog can do that...

A: IOLog is using printf(3) syntax, so ("%c", 176) or (%lc", 0x00b0) should do it. Should. It won't show in my terminal. You could just use °

[Time2Retire]

Done. Look here:

MSRDumper(@34) CoreLoads: 99 99 99 99 99 99 99 99 
MSRDumper(@34) CoreTemps: 36    36    45    45    
MSRDumper(@34) CoreLoads: 99 99 99 99 99 99 99 99 
MSRDumper(@34) CoreTemps: 27    27    37    37    
MSRDumper(@34) CoreLoads: 99 99 99 99 99 99 99 99 
MSRDumper(@16) CoreTemps: 24    24    32    32    
MSRDumper(@16) CoreLoads: 77 78 82 93 97 97 78 76 
MSRDumper(@16) CoreTemps: 25    25    32    32    
MSRDumper(@16) CoreLoads: 61 48 69 47 64 48 59 46 
MSRDumper(@16) CoreTemps: 24    24    31    31

Now (after my hockey training) I want the turbo ratios to be incorporated as well. For this to work I read MSR 0x30A (UCC) and 0x30B (URC) along with MSR_PLATFORM_INFO[15:8] aka the base clock.

 

We can calculate the Turbo activity ratio based on the difference of UCC between each sample period, over the difference of URC difference. The effective frequency of each sample period of the logical processor, p, can be estimated by:

 

(UCC_{n+1, p} - UCC _{n, p}) / (URC_{n+1, p} - URC _{n, p}) * Base_operating_ratio * 100MHz

 

Pffft. Subscript doesn't work.

[flAked]

Great!

 

CoreLoads are for each thread aka virtual processor, right?

 

Reading further on On-Demand Clock Modulation (ODCM) I think it's not very useful for desktop machines. If we set duty cycle to 12.5% this means on effective full load, the CPU will be forced to idle at 87.5% load.

 

It will preserve power consumption and thermal room, but I only see the use in mobile or integrated scenarios, where the CPU is basically "underclocked" to compensate for narrower thermal room or battery power.

 

It will only change the clock modulation when the threshold is reached, therefor in normal idle mode it won't change anything, but only restrict CPU power on higher load.

 

In conclusion, we don't really need it.

 

 

Here is something odd, check out the Geekbench reports here: http://www.tonymacx86.com/viewtopic.php?f=...8&start=200

With Chimera 1.4 they have a Bus Frequency of 5GHz, wicked!

[ThisName]

Hey guys. I have a one-time opportunity to unload my P8P67 PRO and buy a Gigabyte or Asus Z68. I have to decide soon. Are things looking like they're going to happen? Think Asus is going to continue on their own path or will they align with what other manufacturers are doing?

[flAked]

I have a one-time opportunity to unload my P8P67 PRO and buy a Gigabyte or Asus Z68.

I can only tell you that from the looks of the user manual, the Z68 doesn't have the CFG Lock option either. But then again, we haven't had any confirmation that that's the actual setting we are after (could be another lock entirely).

 

There is no conclusive data that proofs SpeedStep is actually working on Gigabyte (ootb). That's why we are working on the monitoring tool. If you look at the MSRDumper thread at tonymac you will see some stepping going on, but only between two states.

 

I honestly don't know how things will work out with the next BIOS updates.

 

I can't give you a definitive answer on wether you should switch boards or not. I can manage with a bin-patched kext. And I wouldn't expect to get things working OOTB with Gigabyte in any case.

[ThisName]

Cool man. Those are good points. I'd like to stick with Asus if I can. I guess we'll know more pretty soon.

[Time2Retire]

Great!

 

CoreLoads are for each thread aka virtual processor, right?

Yup.

 

Reading further on On-Demand Clock Modulation (ODCM) I think it's not very useful for desktop machines. If we set duty cycle to 12.5% this means on effective full load, the CPU will be forced to idle at 87.5% load.

It's only 12.5% when bit 4 isn't set. It is 6.25% when set. Good for 16 different T-States. And when this works without EIST et all in the BIOS enabled, and only when AICPUPM is loaded, instead of NullCPUPM, then we know that AICPUPM is doing something. That the 'cooling devices' (see Linux ACPU dumps) are working.

 

Here is something odd, check out the Geekbench reports here: http://www.tonymacx86.com/viewtopic.php?f=...8&start=200

With Chimera 1.4 they have a Bus Frequency of 5GHz, wicked!

Yeah I told MacMan that this is wrong, to which he replied that he will fix it in a next update. Either him or some other Chameleon developer.

 

Oh and this is something I forgot to mention yesterday; The maximum package power MSR is 2040 (255 Watt) on our boards, but only 960 (120 Watt) on GigaByte boards.

 

I also forgot to attach my mini SSDT to get AICPUPM loaded without errors. This also enables (idle) sleep. That is if you are using my DSDT or fixed your DSDT your self.

ssdt_mini_pr.dsl.zip

[flAked]

It's only 12.5% when bit 4 isn't set. It is 6.25% when set. Good for 16 different T-States. And when this works without EIST et all in the BIOS enabled, and only when AICPUPM is loaded, instead of NullCPUPM, then we know that AICPUPM is doing something. That the 'cooling devices' (see Linux ACPU dumps) are working.

Question is, if and how MSRDumper will show those modulations? From my understanding it will still show the max multiplier but should result in less benchmark points. Oh and temperature of course.

If we want to test this in RevoBoot, we need to disable EIST ourselfs.

 

 

OK, so I changed my APSS and set 30x as my highest multiplier (instead of 37x):

May 26 21:11:37 slave kernel[0]: MSRDumper: multiplier: 16
May 26 21:11:42 slave kernel[0]: MSRDumper: multiplier: 30
May 26 21:11:47 slave kernel[0]: MSRDumper: multiplier: 30
May 26 21:11:52 slave kernel[0]: MSRDumper: multiplier: 30
May 26 21:11:57 slave kernel[0]: MSRDumper: multiplier: 16
May 26 21:12:02 slave kernel[0]: MSRDumper: multiplier: 22
May 26 21:12:07 slave kernel[0]: MSRDumper: multiplier: 16

Et voila. Geekbench score is now 8500 (was 9700).

 

Changing the two highest P-States into overclocked 38x and 39x however, does not work. It will max out on 35x and will not go higher than 58°C.

 

Stupid me. Need to set Turbo max in the BIOS of course.

May 26 22:17:49 slave kernel[0]: MSRDumper: temps:	41° 37° 40°  42° 
May 26 22:17:49 slave kernel[0]: MSRDumper: multiplier: 22
May 26 22:17:54 slave kernel[0]: MSRDumper: temps:	 56° 60° 57° 59° 
May 26 22:17:54 slave kernel[0]: MSRDumper: multiplier: 39
May 26 22:17:59 slave kernel[0]: MSRDumper: temps:	59°57 ° 62°  57° 
May 26 22:17:59 slave kernel[0]: MSRDumper: multiplier: 39
May 26 22:18:04 slave kernel[0]: MSRDumper: temps:   42°   42° 4242° ° 
May 26 22:18:04 slave kernel[0]: MSRDumper: multiplier: 16
May 26 22:18:09 slave kernel[0]: MSRDumper: temps:	 42° 52° 46 43°  
May 26 22:18:09 slave kernel[0]: MSRDumper: multiplier: 39
May 26 22:18:14 slave kernel[0]: MSRDumper: temps:	5448°  52°  49° 
May 26 22:18:14 slave kernel[0]: MSRDumper: multiplier: 39
May 26 22:18:19 slave kernel[0]: MSRDumper: temps:	57°  47° 45° 51° 
May 26 22:18:19 slave kernel[0]: MSRDumper: multiplier: 39
May 26 22:18:24 slave kernel[0]: MSRDumper: temps:  42  42°   42° 42° 
May 26 22:18:24 slave kernel[0]: MSRDumper: multiplier: 16
May 26 22:18:29 slave kernel[0]: MSRDumper: temps:  41°	41°41° 41°  
May 26 22:18:29 slave kernel[0]: MSRDumper: multiplier: 16

Geekbench is now at 10900.

 

BTW, which is the highest temp I should go for? Is 62°C still ok for day to day work?

 

 

Even on my MBP2,2 sysctl shows a fixed value for hw.cpufrequency(min/max), so it's just not used by AICPUPM.

[Time2Retire]

Nice. I see you've managed to get the degree sign in there.

 

I have disabled EIST and all C-States, plus Turbo, in the BIOS but now we need RevoBoot to disable the last bit, and re-enable turbo. Is that correct?

 

Still fighting with the E8/E7 combo because this isn't right (when idle).

 

MSRDumper(@16) CoreLoads: 55 46 56 46 59 46 58 46

 

That must be this factor 100 here:

(actualPerformance * 100) / maximumPerformance)

Can IOLog() handle doubles/floats?

 

Oh and 62° might be fine, but what is the value you get for MSR_TEMPERATURE_TARGET? Here that returns 98°

 

I also attached the diff you've requested

MSRDumper_diff.txt

[flAked]

I have disabled EIST and all C-States, plus Turbo, in the BIOS but now we need RevoBoot to disable the last bit, and re-enable turbo. Is that correct?

What is our objective here? If we are after proof that AICPUPM is in fact throttling the CPU then I believe changing APSS and seeing corresponding multipliers is proof already. APSS is not defined by ACPI 3.0 and therefor there is no way that the BIOS (or rather, hardware-coordinated throttling) is using my updated APSS table?

 

Can IOLog() handle doubles/floats?

Sure, use %f for float/double and %lf for long float/double.

 

Oh and 62° might be fine, but what is the value you get for MSR_TEMPERATURE_TARGET? Here that returns 98°

Which MSR is that, 19C, THERM_STATUS?

[Time2Retire]

What is our objective here? If we are after proof that AICPUPM is in fact throttling the CPU then I believe changing APSS and seeing corresponding multipliers is proof already. APSS is not defined by ACPI 3.0 and therefor there is no way that the BIOS is using my updated APSS table?

But is that the hardware, the BIOS or AICPUPM at work? Have you tried with NullCPUPowerManagement.kext installed? What does that tell you?

 

Sure, use %f for float/double and %lf for long float/double.

Yeah I did that but I got an f instead of anything sane I was expecting. Let's try again now that I am fresh again.

 

Which MSR is that, 19C, THERM_STATUS?

0x1A2