DSDT for Asus P8P67-M PRO

[flAked]

0x1A2

Arg if you search for the whole msr string in the Intel pdf it won't get found...

 

98°C here as well.

[Time2Retire]

Arg if you search for the whole msr string in the Intel pdf it won't get found...

LOL You didn't know? I mean everyone knows that you need to search for: "MSR_ TEMPERATURE_TA RGET"

 

Don't laugh No kidding. Annoying as BEEP.

 

98°C here as well.

Great. Enough headroom I would say. Had it running way over 70°C (with the stock cooler) when I pushed it.

 

Ehm. So this is supposted to work:

IOLog("%f\n", (float) 0.55);

It doesn't. What am I doing wrong?

[flAked]

With NullCPUPM loaded I get a fixed multiplier of 39.

And that is with rdmsr64(0x1A0): 0x850089, so EIST is "enabled" from a hardware perspective.

 

 

Ehm. So this is supposted to work:

IOLog("%f\n", (float) 0.55);

It doesn't. What am I doing wrong?

It is clearly a bug. Documentation states that IOLog is using printf(3) syntax. And if you supply a float to %u for example, then Xcode spawns a warning. So clearly, it checks if %f is matched with a float and it does. But IOLog is not actually outputting it.

 

NSLog is totally happy with %f, there must be a deeper meaning why this isn't allowed for IOService-space.

My guess: 42.

 

 

If you haven't read it, these are my findings with more explanations:

I did some testing, changing BIOS settings and reading out 0x1A0 (MISC_ENABLE).

 

1) EIST + Turbo enabled: 0x850089 + 0x00 (edx)

2) EIST disabled + Turbo enabled: 0x850089 + 0x00 (edx)

3) EIST enabled + Turbo disabled: 0x850089 + 0x40 (edx)

4) EIST + Turbo disabled: 0x850089 + 0x40 (edx)

 

1) is fine

 

2) is the case you mentioned, where EIST is in fact always turned on when Turbo is enabled. But I think the BIOS setting is misleading here. If the sole purpose of tying those two together is to enable users to set Turbo independently, then it makes no sense to even have the option when there is no difference in 1) and 2).

In fact, it would make sense to set a fixed multiplier of say 33x and only turn on Turbo Mode. That way, if thermal allows it, Turbo would kick in from 33 to the defined Turbo Ratio.

Intel specs do not suggest that EIST and Turbo must be tied together.

 

3) is fine, note that 0x40 in edx (high part of the 64bit register) is bit 38 for Turbo that disables it

 

4) is wrong. If both EIST and Turbo are disabled in BIOS, regardless of the design choice in 2), SpeedStep should be disabled completely. EAX should read 0x840089 (bit 16 for EIST).

This is also the case when setting the CPU Ratio manually to 33x. And if C1 is disabled as well.

In fact, if I disable EIST the "Ratio Range" (shown in the Information area above) should either be set to a fixed max_pstate or the custom entered "CPU Ratio". As of now, it shows 16-33 regardless.

[Time2Retire]

Like I said; I have everything disabled in UEFI and I am still testing, but this line:

 

"AppleIntelCPUPowerManagement: Turbo Ratios 1234"

 

Isn't there without this in RevoBoot:

wrmsr64(IA32_MISC_ENABLES, 0x840089);

Note that bit 16 is EIST which I intentionally left out.

[flAked]

I do get the line with EIST disabled, Turbo enabled and a vanilla RevoBoot.

 

But we must remember that those settings are per se buggy and we are on different boards with different BIOSes.

[Time2Retire]

I do get the line with EIST disabled, Turbo enabled and a vanilla RevoBoot.

 

But we must remember that those settings are per se buggy and we are on different boards with different BIOSes.

But I have disabled EIST, Turbo and all C-States in UEFI. My test only demonstrates that we can (re)enable it in RevoBoot.

 

I want turbo ratio switched back on (bit 38) at boot time, but without being forced to use EIST (bit 16). The way I see it, reading several threads about it, we need to disable it... or AICPUPM isn't doing the speed stepping, but the hardware is.

 

I mean when Apple's AICPUPM isn't doing the turbo ratio's, then why print this line:

 

"AppleIntelCPUPowerManagement: Turbo Ratios 1234"

 

and read the MSR for it? You can't do anything with it on a Mac. Right?

[flAked]

But I have disabled EIST, Turbo and all C-States in UEFI. My test only demonstrates that we can (re)enable it in RevoBoot.

My point is that even if you have EIST disabled in the BIOS the bits are not set.

Disabling EIST with wrmsr and seeing what that changes is a good test, though.

 

I also want turbo ratio switched on, but without being forced to use EIST, because the way I see it, reading several threads about it, we need to disable it... or AICPUPM isn't doing the speed stepping, but the hardware is.

I'm not convinced. Think about it, APSS is only accessed by AICPUPM, I changed APSS and now I get stepping according to the new APSS. That can only mean that AICPUPM is doing the stepping. I even left the old _PSS in there, so if the hardware was stepping, it would have used _PSS and gotten to 33x.

 

I'm also not sure that this is wrong, it could be the syntax for a single core setting:

May 27 01:05:28 localhost kernel[0]: AppleIntelCPUPowerManagement: Turbo Ratios 1BBBA
May 27 01:05:28 localhost kernel[0]: AppleIntelCPUPowerManagement: (built 10:29:56 Apr 27 2011) initialization complete

 

 

I mean when Apple's AICPUPM isn't doing the turbo ratio's, then why print this line:

"AppleIntelCPUPowerManagement: Turbo Ratios 1234"

and read the MSR for it? You can't do anything with it on a Mac. Right?

Give the poor kext a break Seriously, we don't know. It might be that it always prints the Turbo Ratios; regardless, we can't conclude anything from it.

[Time2Retire]

My point is that even if you have EIST disabled in the BIOS the bits are not set. Disabling EIST with wrmsr and seeing what that changes is a good test, though.

I get 0x4000850089 with turbo disabled and thus bit 38 reflects my setting. Not so with EIST which I wipe in RevoBoot. So whatever we may need in the near future, we now know that we can do it.

 

I'm not convinced. Think about it, APSS is only accessed by AICPUPM, I changed APSS and now I get stepping according to the new APSS. That can only mean that AICPUPM is doing the stepping.

We are still uncertain about a lot of things. At least I am. This being one of many. I see this as a good thing. We're both attacking it from a different angle. Giving us double the opportunity to strike gold. Or someone else walks in and says; hey. This is it LOL

 

What I did notice, and a couple of times already, that multiplier 22 shows up. How come? Does it match with something Apple is using? Why only 22 and non of the others?

 

I'm also not sure that this is wrong, it could be the syntax for a single core setting:

May 27 01:05:28 localhost kernel[0]: AppleIntelCPUPowerManagement: Turbo Ratios 1BBBA
May 27 01:05:28 localhost kernel[0]: AppleIntelCPUPowerManagement: (built 10:29:56 Apr 27 2011) initialization complete

Oh I have seen this a couple of time (well not exactly the same but...) when I changed the multipliers in the per-core fields. There's also 19999 (when all cores are set to one multiplier) and DEF0 which is when nothing happens.

 

p.s. I am using the stripped down SSDT_PR.dsl and you?

[flAked]

We are still uncertain about a lot of things. At least I am. This being one of many. I see this as a good thing. We're both attacking it from a different angle. Giving us double the opportunity to strike gold. Or someone else walks in and says; hey. This is it LOL

Definitely, yes.

 

What I did notice, and a couple of times already, that multiplier 22 shows up. How come? Does it match with something Apple is using? Why only 22 and non of the others?

This could be a resolution thing, meaning the P-states are changing so quickly that we only see 22. I get the occasional 26 as well. Might be related to just running a stress-test benchmark, meaning it won't call for subtle transitions.

 

Oh I have seen this a couple of time (well not exactly the same but...) when I changed the multipliers in the per-core fields. There's also 19999 and DEF0 which is when nothing happens.

That's something I'm gonna look at tomorrow. Would be interesting to see what is set for iMac12,2. To debug this properly, the correct Turbo State for each CPU would be useful.

 

 

p.s. I am using the stripped down SSDT_PR.dsl and you?

My rev4 that I posted, not stripped down.

[Time2Retire]

Interesting. I compared the _PCT objects, a vital component to get P-States working, of a MacBookPro8,3 with the one found in the iMac12,2 and our Asus ACPI tables. This is what I found out. Let's start with the one found in the MacBookPro8,3:

		Name (_PCT, Package (0x02)
	{
		ResourceTemplate ()
		{
			Register (FFixedHW, 
				[color="#FF0000"]0x00[/color],			   // Bit Width
				[color="#FF0000"]0x00[/color],			   // Bit Offset
				0x0000000000000[color="#FF0000"]000[/color], // Address
				,)
		}, 

		ResourceTemplate ()
		{
			Register (FFixedHW, 
				[color="#FF0000"]0x00[/color],			   // Bit Width
				[color="#FF0000"]0x00[/color],			   // Bit Offset
				0x0000000000000[color="#FF0000"]000[/color], // Address
				,)
		}, 
	})

Here's the one used in the iMac12,2:

		Name (_PCT, Package (0x02)
	{
		ResourceTemplate ()
		{
			Register (FFixedHW, 
				0x10,			   // Bit Width
				0x00,			   // Bit Offset
				0x0000000000000199, // Address
				,)
		}, 

		ResourceTemplate ()
		{
			Register (FFixedHW, 
				0x10,			   // Bit Width
				0x00,			   // Bit Offset
				0x0000000000000198, // Address
				,)
		}
	})

And this is the (factory) one we have:

		Name (_PCT, Package (0x02)
	{
		ResourceTemplate ()
		{
			Register (FFixedHW, 
				[color="#FF0000"]0x40[/color],			   // Bit Width
				0x00,			   // Bit Offset
				0x0000000000000199, // Address
				,)
		}, 

		ResourceTemplate ()
		{
			Register (FFixedHW, 
				0x10,			   // Bit Width
				0x00,			   // Bit Offset
				0x0000000000000198, // Address
				,)
		}
	})

I wonder why Asus wants to read/write all 64 bits (0x40) since 16 (0x10) is all we need. And I might be wrong, but this looks suspiciously like the MSR's we are reading out.

 

Note: I am using the iMac one because of the formentioned reason.

[flAked]

I changed the 0x40 to 0x10 and this is the result:

May 27 14:53:32 slave kernel[0]: MSRDumper: multiplier: 16
May 27 14:53:37 slave kernel[0]: MSRDumper: multiplier: 16
May 27 14:53:42 slave kernel[0]: MSRDumper: multiplier: 39
May 27 14:53:47 slave kernel[0]: MSRDumper: multiplier: 39
May 27 14:53:52 slave kernel[0]: MSRDumper: multiplier: 39
May 27 14:53:57 slave kernel[0]: MSRDumper: multiplier: 39
May 27 14:54:02 slave kernel[0]: MSRDumper: multiplier: 39
May 27 14:54:07 slave kernel[0]: MSRDumper: multiplier: 16
May 27 14:54:12 slave kernel[0]: MSRDumper: multiplier: 30
May 27 14:54:17 slave kernel[0]: MSRDumper: multiplier: 16
May 27 14:54:22 slave kernel[0]: MSRDumper: multiplier: 16
May 27 14:54:27 slave kernel[0]: MSRDumper: multiplier: 30
May 27 14:54:32 slave kernel[0]: MSRDumper: multiplier: 16
May 27 14:54:37 slave kernel[0]: MSRDumper: multiplier: 16
May 27 14:54:42 slave kernel[0]: MSRDumper: multiplier: 26
May 27 14:54:47 slave kernel[0]: MSRDumper: multiplier: 26
May 27 14:54:52 slave kernel[0]: MSRDumper: multiplier: 26
May 27 14:54:57 slave kernel[0]: MSRDumper: multiplier: 26
May 27 14:55:02 slave kernel[0]: MSRDumper: multiplier: 16

At first I thought it only swings between 16 and 39, but after letting it run a while...

 

I wonder why Asus wants to read/write all 64 bits (0x40) since 16 (0x10) is all we need. And I might be wrong, but this looks suspiciously like the MSR's we are reading out.

They might want to read "IDA engange", whatever that is. Or one of the secret reserved bit fields. And yes those are PERF_CTL and PERF_STATUS registers.

 

There is a new beta BIOS for the P8P67 - I shall flash thee.

[Time2Retire]

I changed the 0x40 to 0x10 and this is the result:...

At first I thought it only swings between 16 and 39, but after letting it run a while...

Now try a different value in _PSD.

 

They might want to read "IDA engange", whatever that is. Or one of the secret reserved bit fields. And yes those are PERF_CTL and PERF_STATUS registers.

IDA = Turbo

 

There is a new beta BIOS for the P8P67 - I shall flash thee.

Let's hope this clears the lock bit.

[flAked]

Now try a different value in _PSD.

With 0xFE = HW_ALL I get the same stepping behavior.

 

I'm now trying your stripped down version, to prove that PSD is ignored

 

 

OK, so with the stripped down version with only APSS, ACST and APSN, I get normal stepping.

 

Now, setting "Name(APSS, Zero)" still loads AICPUPM but the multiplier stays the same:

May 27 15:46:54 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:48:42 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:48:47 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:48:52 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:48:57 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:49:02 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:49:07 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:49:12 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:49:17 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:49:22 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:49:27 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:49:32 slave kernel[0]: MSRDumper: multiplier: 16
May 27 15:49:37 slave kernel[0]: MSRDumper: multiplier: 16

This was running Geekbench with 4800 points.

 

 

Now then, defining APSS like so

Name (APSS, Package (0x2) // Performance Supported States, used by SMC_PlatformPlugin
{
Package (0x06) { /* 2200 MHz */ 0x898, 0xd971, 10, 10, /* 22 */ 0x1600, 0x1600 },
Package (0x06) { /* 1600 MHz */ 0x640, 0x92d9, 10, 10, /* 16 */ 0x1000, 0x1000 }
})

 

Will result in the following error:

May 27 16:02:12 slAve kernel[0]: P-State Stepper Error 18 at step 41 on CPU 0
May 27 16:02:12 slAve kernel[0]: P-State Stepper Error 18 at step 37 on CPU 3

 

 

I'm sorry, I neglected APSN, if I do this:

Name (APSS, Package (0x2) // Performance Supported States, used by SMC_PlatformPlugin
{
Package (0x06) { /* 2400 MHz */ 0x960, 0xf2fe, 10, 10, /* 24 */ 0x1800, 0x1800 }, 
Package (0x06) { /* 1600 MHz */ 0x640, 0x92d9, 10, 10, /* 16 */ 0x1000, 0x1000 }
})

Name (APSN, 0x00) // Number of turbo states (see Intel Datasheet for your CPU).

I can set arbitrary P-states.

 

This shows:

May 27 16:21:33 slave kernel[0]: MSRDumper: multiplier: 16
May 27 16:21:38 slave kernel[0]: MSRDumper: multiplier: 24
May 27 16:21:43 slave kernel[0]: MSRDumper: multiplier: 24
May 27 16:21:48 slave kernel[0]: MSRDumper: multiplier: 24
May 27 16:21:53 slave kernel[0]: MSRDumper: multiplier: 24
May 27 16:21:58 slave kernel[0]: MSRDumper: multiplier: 24
May 27 16:22:03 slave kernel[0]: MSRDumper: multiplier: 24
May 27 16:22:08 slave kernel[0]: MSRDumper: multiplier: 24
May 27 16:22:13 slave kernel[0]: MSRDumper: multiplier: 16

With Geekbench score 6700.

 

 

So, what can we take from this?

 

1) With EIST enabled in BIOS (and reflected in the MSR) there is no hardware-controlled throttling going on at all.

2) AICPUPM is only interested in A* definitions (APSS, APSN, ACST)

3) AICPUPM is throttling our CPU (according to APSS)

[davidm71]

Sorry to take you guys off topic but are you aware there were a bunch of new beta bioses just posted on HF? 1606 for the Deluxe board and 1607 for the P8P67-M Evo (not the Pro). Also on Tonymac somebody posted a Kext for the P8P67SataController..

 

As you were..

[flAked]

Yes, thanks.

 

Here is a list of all beta BIOSes (not only for those two mentioned): http://hardforum.com/showpost.php?p=103730...;postcount=2887

 

Apparently they are working on 17** and I think those will be more likely to include bugfixes to our problems, giving the long time those BIOS updates are tested.

 

Also on Tonymac somebody posted a Kext for the P8P67SataController..

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).

[mrmojorisin17]

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).

Look here at 2nd post.

[flAked]

Nothing new, we are doing this in our FakeSMC plist.

mrmojorisin17 made me aware of the fact that our id is already present in AppleAHCIPort.kext and we don't need the injection in FakeSMC. I just confirmed it. I don't know if this was covered already.

 

Now let's have some fun with APSN. Defining this APSS:

Name (APSS, Package (0x3) // Performance Supported States, used by SMC_PlatformPlugin
{
Package (0x06) { /* 3400 MHz */ 0xD48, 0x17318, 10, 10, /* 34 */ 0x2200, 0x2200 }, 
Package (0x06) { /* 2500 MHz */ 0x9C4, 0x10028, 10, 10, /* 25 */ 0x1900, 0x1900 },
Package (0x06) { /* 1600 MHz */ 0x640, 0x92d9, 10, 10, /* 16 */ 0x1000, 0x1000 }
})

Name (APSN, 0x01)

 

This tells AICPUPM that we have 2 P-states (16 and 25) and 1 turbo-state (34).

 

Having Turbo enabled, rdmsr64(0x1A0): 0x850089 gives us:

May 27 18:18:37 slave kernel[0]: MSRDumper: multiplier: 16
May 27 18:18:42 slave kernel[0]: MSRDumper: multiplier: 16
May 27 18:18:47 slave kernel[0]: MSRDumper: multiplier: 34
May 27 18:18:52 slave kernel[0]: MSRDumper: multiplier: 34
May 27 18:18:57 slave kernel[0]: MSRDumper: multiplier: 34
May 27 18:19:02 slave kernel[0]: MSRDumper: multiplier: 16

That's great, so the turbo-state is actually used.

 

Now, if we disable Turbo in the BIOS, rdmsr64(0x1A0): 0x4000850089:

May 27 18:21:44 slave kernel[0]: MSRDumper: multiplier: 16
May 27 18:21:49 slave kernel[0]: MSRDumper: multiplier: 33
May 27 18:21:54 slave kernel[0]: MSRDumper: multiplier: 33
May 27 18:21:59 slave kernel[0]: MSRDumper: multiplier: 33
May 27 18:22:04 slave kernel[0]: MSRDumper: multiplier: 16
May 27 18:22:09 slave kernel[0]: MSRDumper: multiplier: 33
May 27 18:22:14 slave kernel[0]: MSRDumper: multiplier: 33
May 27 18:22:19 slave kernel[0]: MSRDumper: multiplier: 33
May 27 18:22:24 slave kernel[0]: MSRDumper: multiplier: 25
May 27 18:22:29 slave kernel[0]: MSRDumper: multiplier: 16

That is interesting. First of all, our turbo-state (34) is not used, our two P-states are however (16, 25).

33x comes into the mix, which is my highest non-turbo state for the i5-2500K. So is APSN ignored when Turbo is disabled or is AICPUPM using the highest available P-state (per CPU definition) because APSN=1?

 

Another test run... well, confirming this with the following is not very insightful, because we know what that will trigger:

Name (APSS, Package (0x2) // Performance Supported States, used by SMC_PlatformPlugin
{
Package (0x06) { /* 2500 MHz */ 0x9C4, 0x10028, 10, 10, /* 25 */ 0x1900, 0x1900 },
Package (0x06) { /* 1600 MHz */ 0x640, 0x92d9, 10, 10, /* 16 */ 0x1000, 0x1000 }
})

Name (APSN, 0x00)

We have Turbo disabled in the BIOS, APSN is zero and we are defining two p-states. And the log shows:

May 27 19:00:00 slave kernel[0]: MSRDumper: multiplier: 16
May 27 19:00:05 slave kernel[0]: MSRDumper: multiplier: 16
May 27 19:00:10 slave kernel[0]: MSRDumper: multiplier: 25
May 27 19:00:15 slave kernel[0]: MSRDumper: multiplier: 25
May 27 19:00:20 slave kernel[0]: MSRDumper: multiplier: 25
May 27 19:00:25 slave kernel[0]: MSRDumper: multiplier: 25
May 27 19:00:30 slave kernel[0]: MSRDumper: multiplier: 16
May 27 19:00:35 slave kernel[0]: MSRDumper: multiplier: 16

No surprise there. But because we know that APSN is defining the available Turbo states, let's just use it how it is intended. These APSS are constructed to proof a point anyways.

 

 

Additional, with Turbo enabled in the BIOS (set to 39 for all cores):

May 27 18:17:34 localhost kernel[0]: AppleIntelCPUPowerManagement: Turbo Ratios 1BBBA

With Turbo disabled in the BIOS AICPUPM is not outputting the line.

 

 

Now let's find out if that 1BBBA is causing troubles. We will enable Turbo again and define 4 Turbo states:

Name (APSS, Package (0x06) // Performance Supported States, used by SMC_PlatformPlugin
{
Package (0x06) { /* 3900 MHz */ 0xF3C, 0x17318, 10, 10, /* 39 */ 0x2700, 0x2700 },
Package (0x06) { /* 3800 MHz */ 0xED8, 0x17318, 10, 10, /* 38 */ 0x2600, 0x2600 },
Package (0x06) { /* 3700 MHz */ 0xE74, 0x17318, 10, 10, /* 37 */ 0x2500, 0x2500 },
Package (0x06) { /* 3600 MHz */ 0xE10, 0x17318, 10, 10, /* 36 */ 0x2400, 0x2400 },
Package (0x06) { /* 2500 MHz */ 0x9C4, 0x10028, 10, 10, /* 25 */ 0x1900, 0x1900 },
Package (0x06) { /* 1600 MHz */ 0x640, 0x92d9, 10, 10, /* 16 */ 0x1000, 0x1000 }
})

Name (APSN, 0x04)

 

With Turbo ratio set to 39 (for all cores) in the BIOS, regardless if you benchmark with 1,2,3 or 4 threads it will always boost to 39x.

 

Setting the ratio back to 1234 (default) we only see a boost to 34x:

May 27 19:35:38 slave kernel[0]: MSRDumper: multiplier: 34
May 27 19:35:43 slave kernel[0]: MSRDumper: multiplier: 16
May 27 19:35:48 slave kernel[0]: MSRDumper: multiplier: 16
May 27 19:35:53 slave kernel[0]: MSRDumper: multiplier: 34
May 27 19:35:58 slave kernel[0]: MSRDumper: multiplier: 34
May 27 19:36:03 slave kernel[0]: MSRDumper: multiplier: 34

That being the stock 33 + 1. If only one core is loaded, it should go up to 33 + 4 = 37. But because I didn't define those states in my APSS above, it will remain at 34. This is a bit unclear to me, because I didn't define 34 either.

 

Note that those are two different modes. The default (1234) will use the maximum non-turbo multiplier (which you can set in the BIOS) and add up to 4 steps (+4) to that multiplier. Where the fixed ratio will basically disable this stepped behavior and always enable the highest P-states we define in APSS.

 

 

Well, if I use properly crafted APSS with Turbo states 34, 35, 36 and 37 and Turbo ratio is set to 1234, I won't get more than 34x even if only one core is active. It should give me 37x in that case.

 

This was a great run, I think I have proven a lot with it. Turbo is still a missing piece, though. Anyways, off to do some eSports, laters!

[mrmojorisin17]

Nothing new, we are doing this in our FakeSMC plist.

mrmojorisin17 made me aware of the fact that our id is already present in AppleAHCIPort.kext and we don't need the injection in FakeSMC. I just confirmed it. I don't know if this was covered already.

Yep, our sata controller is correctly recognized with new AppleAHCIPort.kext that contains our sata controller id 8086,1c02 and also 8086,1c03 (mobile id?).

I think that FakeSMC.kext Info.plist injection is only required to show the Intel Chipset 6 caption in System Profiler instead of the general Unknown.

[Time2Retire]

Yep, our sata controller is correctly recognized with new AppleAHCIPort.kext that contains our sata controller id 8086,1c02 and also 8086,1c03 (mobile id?).

I think that FakeSMC.kext Info.plist injection is only required to show the Intel Chipset 6 caption in System Profiler instead of the general Unknown.

Correct. The new device-id came with the kext update, and yes still required to identify it in System Profiler (because some IRQ is blocking us from getting what we need).

 

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

 

 

Test version of ssdt_pr.dsl attached. Only to be used by people who know what to do with it. And no. This is not the final version of ssdt_pr.dsl Just a test vehicle to check the bits. Was a bit of work but this way works.

 

And by adding If() clauses in CPU1-7 you can see how many bits are set. For this you check:

 

IOPMrootDomain -> Power Status -> CPU_Power_Limits -> CPU_Available_CPUs

 

That will tell you how many bits are set, but not which bits. For that we have another If() clause in the DSL.

 

Have fun with it!

ssdt_pr_pdc0_test.dsl.zip

[mrmojorisin17]

Correct. The new device-id came with the kext update, and yes still required to identify it in System Profiler (because some IRQ is blocking us from getting what we need).

Thanks for confirmation

[Time2Retire]

I am trying to reproduce the things you have done, but it doesn't work here.

 

Let's start with the MD5 of your AppleIntelCPUPowerManagment binary. What is that?

 

Also. You wrote to use a stripped down copy of ssdt_pr.dsl with only APSS in it, but here it won't even start. Or only with errors because it lacks ACST in it. You don't get the error?

 

Better attach your copy because now this is more of an apples versus oranges story. Can't compare without know what to look for.

[flAked]

Also. You wrote to use a stripped down copy of ssdt_pr.dsl with only APSS in it, but here it won't even start. Or only with errors because it lacks ACST in it. You don't get the error?

Ahh sorry, wasn't very clear on that point. I took your stripped down version with APSS, ACST and APSN in it and worked from there. Oops my bad, I actually wrote that I only used APSS, that was wrong.

 

AICPUPM md5 is 2f4f8fbd071c3e59020484e07732ced1

[Time2Retire]

Ahh sorry, wasn't very clear on that point. I took your stripped down version with APSS, ACST and APSN in it and worked from there. Oops my bad, I actually wrote that I only used APSS, that was wrong.

 

AICPUPM md5 is 2f4f8fbd071c3e59020484e07732ced1

Ah ok. BTW MD5 is different (72dc51de9a0c3b803011784341399c9f).

 

Stupid turbo feature... 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?

[flAked]

Ah ok. BTW MD5 is different (72dc51de9a0c3b803011784341399c9f).

What's the version and md5 of the original?

 

 

I have to disabled EIST in the BIOS or turbo won't kick in.

I'm still put off by this. Will disabling EIST in your BIOS actually set the bit for it? Otherwise this shouldn't matter.

[Time2Retire]

What's the version and md5 of the original?

One of these (I'm on 10K524):

5573c81d6dda62bcc150016b10b8bc1b = 10K524

d6158b61e62dc4d44c7f7a5f84b44354 = 10K421

 

I'm still put off by this. Will disabling EIST in your BIOS actually set the bit for it? Otherwise this shouldn't matter.

The one we thought it to be (0x1A0) isn't changing.