DSDT for Asus P8P67-M PRO

[davidm71]

Link please? I presume for the Marvell Sata ports? I don't have any devices plugged in there, but the two extra SATA ports are being recognized here without problems (correct DSDT of course).

 

Here are those links. Going to try these kexts out shortly or should I not bother and use a dsdt instead?

 

http://www.tonymacx86.com/viewtopic.php?f=...60&start=10

http://www.kexts.com/view/1250-p8p67sataco...llers.kext.html

[flAked]

d6158b61e62dc4d44c7f7a5f84b44354

This is the md5 of my original.

 

But if the patcher finds all wrmsr on the fixed offsets and your kext is loading it is highly unlikely that something else is going on. Perhaps they just changed a version string...

 

News: PDC0 is 0x19 and thus only bit 0, 3 and 4 are set.

Bit 5 sounds nice, isn't it?

 

How is PDC0 set, can we change it?

 

I have to disabled EIST in the BIOS or turbo won't kick in. Wait a second. Does this mean that AICPUPM does turbo now? Or just that EIST blocks it?

Double-checked that you didn't change anything else?

 

So with your APSS you get 34x (EIST enabled) and 38x (EIST disabled) correct?

 

How is your Turbo Ratio set? What happens if you run Prime95 on 1 thread?

[Time2Retire]

Bit 5 sounds nice, isn't it?

 

How is PDC0 set, can we change it?

This is done by OSPM and we can't change it.

 

Double-checked that you didn't change anything else?

I even restored the defaults.

 

So with your APSS you get 34x (EIST enabled) and 38x (EIST disabled) correct?

35 when Geekbench runs (otherwise I see 16 most of the time).

 

How is your Turbo Ratio set?

1, 2, 3, 4.

 

What happens if you run Prime95 on 1 thread?

Never used it before. Will Google it.

[flAked]

ftp://mersenne.org/gimps/Prime95-MacOSX-266.zip

 

I think it will start doing some crunching right away. Just go to Test->Stop.

Then you can Options->Torture Test... and enter 1 thread.

 

35 when Geekbench runs (otherwise I see 16 most of the time).

That seems to be the behavior I get as well, being max non turbo state +1.

34 in my case.

[Time2Retire]

I think it will start doing some crunching right away. Just go to Test->Stop. Then you can Options->Torture Test... and enter 1 thread.

 

That seems to be the behavior I get as well, being max non turbo state +1.

34 in my case.

Yup. Got it. Thanks.

 

Right. 35 here. However. At boot time I see it go up to 38 (max) so it appears to work properly.

 

I see (MSR 0x19C) that the i5-2400S CPU is running at 47 degrees Celsius (86 - 39)

 

MSR: 0x19A, 0x1AA, 0x606, 0x640 and 0x640 are the same.

 

But look at 0x198. We don't have that. This might be it. Look at it: 0x21C9 The 21 is the multiplier (FID) and the C9 here must be the VID (Voltage). Nah. That indicates the maximum bus ratio configured for the processor. We just don't have that in there. Strange.

 

RAPL (0x610) set to 520 / 8 = 65 Watt. Conform Intel spec. We could do the same; 95 * 8 = 760 (0x2f8) but Apple also set an upper limit of 650 Watt (0x28A). Very interesting...

[flAked]

On SNB, Bits 47:32 of 0x198 are Core Voltage (R/O)

[Time2Retire]

On SNB, Bits 47:32 of 0x198 are Core Voltage (R/O)

Right. Old one (April 2011) deleted and a new one (May 2011) put in place. Thanks. Ah yes. Running on 1.06 Volt. Nice.

 

Now the question is: Why don't we Asus / GigaByte users see this data?

 

Oh and writing MSR 0x610 doesn't stick. Still getting the old value.

[flAked]

Remember the random LPC error I got that I wasn't able to pin down?

 

After over 30 boots in different situations I'm fairly certain that I fixed it once and for all.

 

If anyone else is having this problem, it is related to /Extra/Extensions.mkext changing when using a Boot-CD / USB-Stick with a different configuration set. Removing /Extra completely and placing your kexts in /S/L/E as it should be fixes the issue.

 

 

NEWS: PDC0 bit 5 is set on my system, as well as 0, 3 and 4.

 

 

Onwards. I accepted that stripping down SSDT_PR was an experiment. Right. So I loaded up my full-fledged version with my current mindset and this is what I got:

May 28 12:20:52 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:20:57 slave kernel[0]: MSRDumper: multiplier: 22
May 28 12:21:02 slave kernel[0]: MSRDumper: multiplier: 26
May 28 12:21:07 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:21:12 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:21:17 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:21:22 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:21:27 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:21:32 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:21:37 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:21:42 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:21:47 slave kernel[0]: MSRDumper: multiplier: 36
May 28 12:21:52 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:21:57 slave kernel[0]: MSRDumper: multiplier: 36
May 28 12:22:02 slave kernel[0]: MSRDumper: multiplier: 36
May 28 12:22:07 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:22:12 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:22:17 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:22:22 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:22:27 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:22:32 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:22:37 slave kernel[0]: MSRDumper: multiplier: 16
-------------------------------
May 28 12:22:42 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:22:47 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:22:52 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:22:57 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:23:02 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:23:07 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:23:12 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:23:17 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:23:22 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:23:27 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:23:32 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:23:37 slave kernel[0]: MSRDumper: multiplier: 16
---------------------------------------
May 28 12:23:42 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:23:47 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:23:52 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:23:57 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:24:02 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:24:07 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:24:12 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:24:17 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:24:22 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:24:27 slave kernel[0]: MSRDumper: multiplier: 34
May 28 12:24:32 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:24:37 slave kernel[0]: MSRDumper: multiplier: 16

 

These are the load scenarios for 1 thread, 2 threads and 4 threads in Prime95.

 

It never reaches 37x (very conservative setting?) but it clearly shows that it will go to 36x on a single thread and only to 34x on multiple threads.

 

So what does that mean?

1) Turbo is not working with a stripped down version of SSDT_PR, we need other components as well

2) The scaling is not as linear as I thought or we are missing another piece

 

 

Now, let's be sneaky and figure out how AICPUPM is using the Turbo Ratio defined in the BIOS.

We have 1234 set per default, the question is if those numbers are directly used to increment the multipliers or if AICPUPM is using a scaling/stepping of its own.

 

Let's change 36 and 37 into 38 and 39 in the APSS. Here are the results:

May 28 12:49:14 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:49:19 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:49:24 slave kernel[0]: MSRDumper: multiplier: 36
May 28 12:49:29 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:49:34 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:49:39 slave kernel[0]: MSRDumper: multiplier: 35
May 28 12:49:44 slave kernel[0]: MSRDumper: multiplier: 22
May 28 12:49:49 slave kernel[0]: MSRDumper: multiplier: 16
May 28 12:49:54 slave kernel[0]: MSRDumper: multiplier: 16

 

36x again for a single benchmark thread. But we replaced the 3rd turbo state with 38x ?!

 

That can only mean one thing: we can't arbitrarily change the turbo states, because AICPUPM is using the Turbo Ratio directly!

 

So if the ratio is defined as 1234, then AICPUPM will just take 33 + 3 = 36 (for the 3rd turbo state).

This is expected behavior, I was only wondering how APSS and APSN play a role here.

 

 

Now I'm curious. What will happen if we set the ratio to 1256 (39, 38, 35, 34)?

May 28 13:07:04 slave kernel[0]: MSRDumper: multiplier: 16
May 28 13:07:09 slave kernel[0]: MSRDumper: multiplier: 35
May 28 13:07:14 slave kernel[0]: MSRDumper: multiplier: 35
May 28 13:07:19 slave kernel[0]: MSRDumper: multiplier: 35
May 28 13:07:24 slave kernel[0]: MSRDumper: multiplier: 35
May 28 13:07:29 slave kernel[0]: MSRDumper: multiplier: 38 <----
May 28 13:07:34 slave kernel[0]: MSRDumper: multiplier: 35
May 28 13:07:39 slave kernel[0]: MSRDumper: multiplier: 35
May 28 13:07:44 slave kernel[0]: MSRDumper: multiplier: 35
May 28 13:07:49 slave kernel[0]: MSRDumper: multiplier: 35
May 28 13:07:54 slave kernel[0]: MSRDumper: multiplier: 35
May 28 13:07:59 slave kernel[0]: MSRDumper: multiplier: 16

Those four are the turbo states I have currently defined in my APSS. And we see that on a single thread it now goes up to 38x!

 

Good. Setting different ratios in the BIOS will get picked up by AICPUPM, the log shows:

May 28 13:05:13 localhost kernel[0]: AppleIntelCPUPowerManagement: Turbo Ratios 1256

 

The question remains why the last state (max turbo state) is never reached and the 3rd state is only active briefly.

 

Let's have a hot beverage and think about it

 

 

Remember this line from _PSS?

Package (0x06) { /* 3301 MHz */ 0xCE5, 0x17318, 10, 10, /* 37 */ 0x2500, 0x2500 }

It is used to set maxW and maxMultiplier (meta state).

 

Guess what? ACPI_SMC_PlatformPlugin is reading _PSS!

 

Doesn't matter, still only the occasional 38x on 1 thread load.

 

Of course, after typing this I get:

May 28 13:44:22 slave kernel[0]: MSRDumper: multiplier: 16
May 28 13:44:27 slave kernel[0]: MSRDumper: multiplier: 16
May 28 13:44:32 slave kernel[0]: MSRDumper: multiplier: 34
May 28 13:44:37 slave kernel[0]: MSRDumper: multiplier: 34
May 28 13:44:42 slave kernel[0]: MSRDumper: multiplier: 34
May 28 13:44:47 slave kernel[0]: MSRDumper: multiplier: 34
May 28 13:44:52 slave kernel[0]: MSRDumper: multiplier: 26
May 28 13:44:57 slave kernel[0]: MSRDumper: multiplier: 38
May 28 13:45:02 slave kernel[0]: MSRDumper: multiplier: 16
May 28 13:45:07 slave kernel[0]: MSRDumper: multiplier: 35
May 28 13:45:12 slave kernel[0]: MSRDumper: multiplier: 38
May 28 13:45:17 slave kernel[0]: MSRDumper: multiplier: 39 <----
May 28 13:45:22 slave kernel[0]: MSRDumper: multiplier: 16
May 28 13:45:27 slave kernel[0]: MSRDumper: multiplier: 38
May 28 13:45:32 slave kernel[0]: MSRDumper: multiplier: 16

This was with no benchmark running, so it could be that it won't boost into the highest state if the CPU is under full load but rather if everything is idle and something needs computation then it will boost.

 

Great, now I don't know if adding _PSS back in did the trick.

[Time2Retire]

NEWS: PDC0 bit 5 is set on my system, as well as 0, 3 and 4.

...

 

Great, now I don't know if adding _PSS back in did the trick.

I don't have bit 5 set. Unfortunately not. This is a major issue that I have to track down first, or other people will most certainly run into the same issue.

 

Is this due to changes in the BIOS or ssdt_pr.dsl? With or without _PSS and/or _PSD et all?

 

Can you please attach your dsdt.dsl because I am starting to wonder if I haven't been changing something too much (for the next release). I also have a old test DSDT that panics on 10.6.8 but boots with 10.6.7.

 

Did you flash the BIOS yet? What version are you using right now? Do I need windows for this – remember I don't have Windows?

 

Do you see something like: AGPM: board_id = Mac-942B59F58194171B in kernel.log?

 

p.s. Did you miss post #548 (no downloads yet)?

[mrmojorisin17]

Did you flash the BIOS yet? What version are you using right now? Do I need windows for this – remember I don't have Windows?

For update BIOS version?

You can update BIOS directly from BIOS itself using an USB key.

[Time2Retire]

For update BIOS version? You can update BIOS directly from BIOS itself using an USB key.

Yes. For everything a first time they say... never don't this myself. Scared to break it...

 

That's why we have a manual. Chapter 2.1.2 is helpful. USB stick with FAT16/32 format (one partition) with the downloaded file on it. Easy. Thanks.

 

The update to 709 went surprisingly easy. Still no bit 5...and without bit 5 set, there won't be software coordinated P-State changes.

[mrmojorisin17]

Is not a dangerous process

You have only to put new BIOS version on an USB key and then go to Asus Flash Utility in BIOS, select the new BIOS from the USB key and then follow the instructions.

 

That's why we have a manual. Chapter 2.1.2 is helpful. USB stick with FAT16/32 format (one partition) with the downloaded file on it. Easy. Thanks.

You're welcome

[flAked]

Is this due to changes in the BIOS or ssdt_pr.dsl? With or without _PSS and/or _PSD et all?

These tests were only made changing SSDT_PR. I need to confirm that PSS is changing anything, PSD is present yes.

 

BIOS settings for the tests have been:

 

EIST enabled

Turbo enabled

C-states all enabled

 

Can you please attach your dsdt.dsl...

dsdt.dsl.zip

 

Did you flash the BIOS yet? What version are you using right now?

No, I'm still on 1503. The new 16** beta have been in the works for weeks, I don't think it will change much and I don't want to change my test-environment right now.

 

Do you see something like: AGPM: board_id = Mac-942B59F58194171B in kernel.log?

Nope, this has nothing todo with modding the plist for AGPM or is it? Because I haven't done that yet.

 

p.s. Did you miss post #548 (no downloads yet)?

Oh wow, indeed. Thanks!

 

 

This is my current test-vessel, don't use it people!

ssdt_pr_minimal_rev5.dsl.zip

[Time2Retire]

These tests were only made changing SSDT_PR. I need to confirm that PSS is changing anything, PSD is present yes.

Yes please. Thanks.

 

BIOS settings for the tests have been:

 

EIST enabled

Turbo enabled

C-states all enabled

Same here. I only disabled the serial port, parallel port, Marvell and USB3 controllers. Well that and this stupid boot screen.

 

Nope, this has nothing todo with modding the plist for AGPM or is it? Because I haven't done that yet.

Forget it. Got that after booting into 10.6.7 (can be found in AppleGraphicsPowerManagement).

 

I'll have a look at the ACPI files now...

[flAked]

I think I found a bug in your patch, the multiplier won't go higher than 34 at all time, where my version shows 38.

[mrmojorisin17]

A new 10.6.8 build (10K531) was released this morning from Apple to developer.

[Time2Retire]

I think I found a bug in your patch, the multiplier won't go higher than 34 at all time, where my version shows 38.

 

I'm trying to find why.

Oh marvelous. I hope that you can locate the bug. But this won't fix my bit 5 issue I think.

 

Say. What was the 'Stepper CPU' value (IOPMrootDomain) again? And this value changes when you disable ESIT/Turbo?

 

Also. Are you using the SMBIOS mod or not?

 

p.s. The SATA controller needs two IRQ's assigned, but here I only have one - hence me getting AppleACPI instead of AppleIntelPchSeriesAHCI.

 

Need to go for some time now. Back later...

 

p.s. Already have 10K531 – since yesterday evening

[flAked]

Oh marvelous. I hope that you can locate the bug. But this won't fix my bit 5 issue I think.

If you comment out everything in the eventTimer but:

UInt8 multi = rdmsr64(0x198) >> 8;

and output that, you will see higher multipliers.

 

Reading out the sensor data every second seems to influence the actual speed. The 500 ticks I set in my code correspond to roughly 5 seconds. But even then, the readouts are affecting the multiplier.

 

Also, 0x198 is per package, so it makes no sense to call getMultiplier on every core.

 

Say. What was the 'Stepper CPU' value (IOPMrootDomain) again? And this value changes when you disable ESIT/Turbo?

Right now it's: 0x1fe0007

Let's reboot. I tested every combination, it doesn't change.

 

Also. Are you using the SMBIOS mod or not?

No. But I will flash the BIOS and see if the USBF errors/holdups will vanish then.

 

p.s. The SATA controller needs two IRQ's assigned, but here I only have one - hence me getting AppleACPI instead of AppleIntelPchSeriesAHCI.

We should have a second look at that kext, they do it a bit differently than in our FakeSMC plist.

 

 

Did a couple of tests regarding _PSS. It is not necessary. The same goes for the alias:

Alias(APSS, _PSS)

 

A quick tip about MSRDumper: don't copy it to /S/L/E and let it load on boot-time, it will clear out important boot messages! For example I wasn't able to see this, if MSRDumper was loaded on boot:

May 28 19:27:54 localhost kernel[0]: AppleIntelCPUPowerManagement: Turbo Ratios 2356

And I first thought that _PSS is indeed necessary because of this...

 

As you can see I'm experimenting with Turbo Ratios, bumping it up because the load-balancing seems so conservative.

 

 

OK, I flashed to 1608:

 

The bad news is that CFG Lock bit 15 is still set.

 

But the SMBIOS fix no longer gives me any USBF subsystem errors. The debug output of SMBIOS shows:

May 28 20:08:39 localhost kernel[0]: SMBIOS: processor type = 0x0603
May 28 20:08:39 localhost kernel[0]: SMBIOS: Bus speed (MT/s) = 0
May 28 20:08:39 localhost kernel[0]: SMBIOS: CPU speed (MHz) = 3310
May 28 20:08:39 localhost kernel[0]: SMBIOS: FSB speed (MT/s) = 100

 

Most importantly EIST + Turbo (still) works with the new BIOS and the SMBIOS fix.

[Time2Retire]

If you comment out everything in the eventTimer but:

UInt8 multi = rdmsr64(0x198) >> 8;

and output that, you will see higher multipliers.

Let me try that.

 

Also, 0x198 is per package, so it makes no sense to call getMultiplier on every core.

Which is too bad, but I think to have found something else for it.

 

We should have a second look at that kext, they do it a bit differently than in our FakeSMC plist.

We should yes.

 

Did a couple of tests regarding _PSS. It is not necessary. The same goes for the alias:

Alias(APSS, _PSS)

Yanked down already.

 

OK, I flashed to 1608:

 

The bad news is that CFG Lock bit 15 is still set.

Ah what a surprise. I'm on 709 now and found a few small changes:

--- Factory 703/DSL/dsdt.dsl	2011-05-28 21:42:35.000000000 +0200
+++ Factory 709/DSL/dsdt.dsl	2011-05-28 21:41:59.000000000 +0200
@@ -5,9 +5,9 @@
 * 
 * Original Table Header:
 *     Signature        "DSDT"
- *     Length           0x000083AD (33709)
+ *     Length           0x000083B6 (33718)
 *     Revision         0x02
- *     Checksum         0x9A
+ *     Checksum         0x52
 *     OEM ID           "ALASKA"
 *     OEM Table ID     "A M I"
 *     OEM Revision     0x00000000 (0)
@@ -15,7 +15,7 @@
 *     Compiler Version 0x20051117 (537202967)
 */

DefinitionBlock ("dsdt.aml", "DSDT", 2, "ALASKA", "A M I", 0x00000000)
{
    Name (SP1O, 0x2E)
    Name (IO1B, Zero)
@@ -1508,7 +1508,7 @@
                }
            }

-            OperationRegion (NBNV, SystemMemory, 0xBF5FCD98, 0x0100)
+            OperationRegion (NBNV, SystemMemory, [color="#FF0000"]0xBF5CBD98[/color], 0x0100)
            Field (NBNV, AnyAcc, Lock, Preserve)
            {
                NBSG,   32, 
@@ -2361,7 +2361,8 @@
                        ShiftLeft (IOAH, 0x08, IO11)
                        Or (IOAL, IO11, IO11)
                        Store (IO11, IO12)
-                        Store (0x08, LEN1)
+                        Subtract (FindSetRightBit (IO11), One, Local0)
+                        ShiftLeft (One, Local0, LEN1)
                        If (INTR)
                        {
                            ShiftLeft (One, INTR, IRQM)
@@ -6211,8 +6212,8 @@

    Scope (_PR)
    {
-        OperationRegion (SSDT, SystemMemory, 0xBF60E898, 0x06F4)
-        OperationRegion (CSDT, SystemMemory, 0xBF605D98, 0x00E4)
+        OperationRegion (SSDT, SystemMemory, 0xBF5DD898, 0x06F4)
+        OperationRegion (CSDT, SystemMemory, 0xBF5D4D98, 0x00E4)
        Name (NCST, 0x02)
        Name (NPSS, 0x10)
        Name (HNDL, 0x80000000)
@@ -8074,7 +8075,7 @@

    Scope (_SB)
    {
-        Name (RAMB, 0xBF5D2018)
+        Name (RAMB, 0xBF5A1018)
        OperationRegion (\RAMW, SystemMemory, RAMB, 0x00010000)
        Field (RAMW, ByteAcc, NoLock, Preserve)
        {

Only one change that matters for us (the rest is stripped out).

 

But the SMBIOS fix no longer gives me any USBF subsystem errors. The debug output of SMBIOS shows:...

 

Most importantly EIST + Turbo (still) works with the new BIOS and the SMBIOS fix.

That's all good then.

 

Now something else again. Look at this (highest temps during two Geekbench runs):

 

MSRDumper(@46) CoreTemps: 64° 72° 75° 65°

MSRDumper(@46) CoreLoads: 135 135 135 135 135 135 135 135

 

34 * 1.35 = 45.9

 

MSRDumper(@47) CoreTemps: 65° 75° 75° 73°

MSRDumper(@47) CoreLoads: 138 138 138 138 138 138 138 138

 

34 * 1.38 = 46.92

 

MSRDumper(@49) CoreTemps: 58° 64° 75° 63°

MSRDumper(@49) CoreLoads: 144 144 144 144 144 144 144 144

 

34 * 1.44 = 48.96

 

MSRDumper(@50) CoreTemps: 64° 77° 79° 75°

MSRDumper(@50) CoreLoads: 147 147 147 147 147 147 147 147

 

34 * 1.47 = 49.98

 

We do miss a small fraction here (because of how this is calculated) but they do match. The same applies to values below 100. This way we can get the actual P-State.

 

Oh and looking at your (flAked) DSDT I noticed two things; You have HDEF commented out (might be important) and the _SUN property was fixed in a later update, but yours doesn't include it:

            Device (P0P2) // Renamed from: P0P1
           {
               Name (_ADR, 0x00010000)
               Alias (AR01, _PRT)
               Alias (PW94, _PRW)

               Device (GFX0)		// Newly added (to add the name).
               {
                   [color="#FF0000"]Name (_SUN, One)[/color]
                   Name (_ADR, Zero)
               }

               Device (HDAU)		// Newly added (to add the name).
               {
                   Name (_ADR, One)
               }
           }

Just to let you know

[flAked]

MSRDumper(@46) CoreTemps: 64° 72° 75° 65°

MSRDumper(@46) CoreLoads: 135 135 135 135 135 135 135 135

 

34 * 1.35 = 45.9

Interesting, so this could explain the "conservative" stepping I'm seeing? Because we are missing a tiny fraction?

But how can we influence it if ever?

 

Oh and looking at your (flAked) DSDT I noticed two things; You have HDEF commented out (might be important) and the _SUN property was fixed in a later update, but yours doesn't include it:

_SUN was just for cosmetics in the profiler am I right? Later update as in osx update or a dsdt update by you?

 

 

v713 @ ASUS FTP: ftp://ftp.asus.com.tw/pub/ASUS/mb/LGA1155/P8P67-M_PRO/

[Time2Retire]

Interesting, so this could explain the "conservative" stepping I'm seeing? Because we are missing a tiny fraction? But how can we influence it if ever?

The MSR's 0xE7/0xE8 are just a way for applications to gain access to the stepper data, but the way we do the our calculations now, is not accurate (enough). Not that it matters. The CPU Stepper appears to be working. That is important.

 

I wish I could somehow fix this stupid bit-5 bug, but I have no idea what to do. That is, if it is even possible. Might be my AppleIntelCPUPowerManagement binary. No idea.

 

The problem I was having before was that I had values in the fifties. At idle time. Making me wonder why. Then I started to do some OC'ing and then it hit me. I realized that the fifties, like 55 for example, is in fact 55% of the normal top frequency. In my case 3.4GHz

 

_SUN was just for cosmetics in the profiler am I right? Later update as in osx update or a dsdt update by you?

Yes it is. A cosmetic only feature. Added by me in a hurry. Didn't work because I had placed it in wrong spot. That (error) was later corrected. In one of my updates.

 

v713 @ ASUS FTP: ftp://ftp.asus.com.tw/pub/ASUS/mb/LGA1155/P8P67-M_PRO/

Thanks. Is that a beta? Wasn't there this afternoon (on the Asus website). What was changed for this update?

[flAked]

Thanks. Is that a beta? Wasn't there this afternoon (on the Asus website). What was changed for this update?

It was uploaded the same day as the other beta bioses, so I would guess pretty much the same changelog, but maybe some individual fixes for that board.

[Time2Retire]

It was uploaded the same day as the other beta bioses, so I would guess pretty much the same changelog, but maybe some individual fixes for that board.

Doesn't look like I'm interested in it, but one never knows so I'll do this in the morning.

 

Oh and like I said; I noticed that HDEF was commented out in your DSDT. Might be related. Maybe OSPM is setting bit 5 based on what it finds, or didn't find. Trying to rule out errors / differences. So that bit is set with audio being fully functional?

 

If yes then I am at a loss as to what to next...

 

Please don't tell me that all cores step up/down (at the same time) on Windows. It doesn't. Right?

[flAked]

I found something! I did another round of slowly removing components of SSDT_PR.

 

The stripped down version of ACST with only one "Package (0x40)" never goes beyond 35x where the old version happily steps to 39x. Need to do one more test, then I will post the differences and a new minimal SSDT_PR.

 

In the latest boot I included HDEF and _SUN. I haven't checked PDC0 yet, but everything working suggests that it's not changing it.

 

 

Right, so basically the difference between the mini SSDT_PR you posted and this one is the full ACST.

This version gives me the full stepping with turbo modes, where the stripped down ACST only stepped between 16 and 35.

 

You should be able to test this by swapping out ACST in your mini SSDT_PR.

 

ssdt_pr_minimal_stripped_rev5.dsl.zip

[flAked]

Please don't tell me that all cores step up/down (at the same time) on Windows. It doesn't. Right?

Well, the performance state transition is defined for the whole package and turbo ratios are defined having the load of all cores in a mind.

 

I don't know how it is implemented internally in the CPU, but the way I see it, if the load shows only one core active than the entire package (including all physical and logical cores) are stepped up for a brief moment of time.

 

The load balancing happens so quickly that if the situation changes and more than one core is active, the turbo ratio will be adjusted accordingly.

 

Internally, the non-active cores might not be stepped up at all.

 

The concept boils down to efficiently using the available TDP, so turbo boost multipliers are tied to the overall thermal headroom.

 

-------------------------------

 

I don't know what's working for you at the moment. I did find that benchmarking the turbo multipliers is not always conclusive.

 

Please do the following

1) strip down MSRDumper so it will only output the global multiplier, nothing else. setTimeoutTicks(500).

2) let it run for 30 minutes, run some programs, do some browsing, etc. but no benchmarking

3) attach it here so I can get an idea

 

Your expected turbo multipliers with 1234 are 35, 36, 37, 38 correct?