DSDT for Asus P8P67-M PRO

[Time2Retire]

Just red...

How you get AppleIntelCPUPowerManagement.kext work correctly?

I bin-patched it.

 

I asked flAked for help (per PM) with the things that we need to do now. Trust me. We will soon all enjoy full power management on our Sandy Bridge platform, and sleep, but we have to make absolutely sure that everything works like we want. And evidently show some proof that it works. Not that it just prevents the KP from happening. Which itself is a great start, but we want (need really) all of it don't we

[sickofit]

when you speek of "all", do you mean all revoboot users or is it a fix that can/will be applied to the other chameleon branches as well? since i require dual boot for windows, i wont ever be able to switch (or i would need a second computer...)

[Time2Retire]

when you speek of "all", do you mean all revoboot users or is it a fix that can/will be applied to the other chameleon branches as well? since i require dual boot for windows, i wont ever be able to switch (or i would need a second computer...)

All as is everyone with a Sandy Bridge setup. Not just RevoBoot users.

[mrmojorisin17]

when you speek of "all", do you mean all revoboot users or is it a fix that can/will be applied to the other chameleon branches as well? since i require dual boot for windows, i wont ever be able to switch (or i would need a second computer...)

I have a dual-boot (Snow Leopard-Windows).

I boot Snow Leopard with RevoBoot and Windows with Boot CD (that use Chameleon).

No problem

[flAked]

Finally, some good news

 

I tried bin-patching a while ago, but it didn't work, maybe I missed a spot, maybe I was too tired that day.

 

Please note that bin-patching all wrmsr is probably not what we want and may cause issues down the road. So it's a proof of concept, but we will need to figure out which occurrence is responsible for the crash.

 

We have 16 wrmsr is that correct? So we need a test-matrix and a lot of reboots...

 

 

And please be patient, as soon as we have a version for you to test, we will post it. Be sure of it! In the mean-time, calm down and have some tea

[Time2Retire]

Finally, some good news

 

I tried bin-patching a while ago, but it didn't work, maybe I missed a spot, maybe I was too tired that day.

 

Please note that bin-patching all wrmsr is probably not what we want and may cause issues down the road. So it's a proof of concept, but we will need to figure out which occurrence is responsible for the crash.

Correct.

 

We have 16 wrmsr is that correct? So we need a test-matrix and a lot of reboots...

That is why I PM'ed you for help. I mean this is a lot of work for me alone, and it is getting late already so... better work together and get things done than to burn out and get no sleep at all LOL

 

I found some Intel doc. Let me get it... Here are the two most important lines:

Always set the undefined or reserved bits in an MSR to the values previously read.

 

Specifying a reserved or unimplemented MSR address in ECX will also cause a general protection exception.

That is why it panics. We have 0x1E008407 in MSR 0x2e but Apple writes 0x18000407 into it (see panic dump). Completely ignoring the lock bit. I think that this is the fifth write instruction in AppleIntelCPUPowerManagement, but there are more places to check.

 

Wait. I have the load address and I think that we should combine that with the address from the panic. Let's trigger a panic and see where it stops (I have to do this because I am using 10.6.8)...

[flAked]

Don't we need to patch every write to 0x2E regardless because the CFG Lock will always cause a GPF?

 

There are 16 references to 0x2E, I will trace it down and see if there is always a write.

[Time2Retire]

This one is trouble for us:

00000000000089bf	movw	$0x00e2,%cx
00000000000089c3	rdmsr
00000000000089c5	movq	%rdx,%rcx
00000000000089c8	shlq	$0x20,%rcx
00000000000089cc	movq	%rax,%rdx
00000000000089cf	andl	$0xfffffb8f,%edx
00000000000089d5	orq	%rcx,%rdx
00000000000089d8	orq	$0x08,%rdx
00000000000089dc	movl	$0x000000e2,%ecx
00000000000089e1	movq	%rdx,%rax
00000000000089e4	andl	$0xff,%eax
00000000000089e7	shrq	$0x20,%rdx
00000000000089eb	wrmsr

$0xfffffb8f will take out 0x400 and we don't want that. Need to be changed to 0xFFFFFF8F There are two (or more of these. And this one is also a problem:

0000000000009924	pushq	%rbp
0000000000009925	movq	%rsp,%rbp
0000000000009928	movl	$0x000000e2,%ecx
000000000000992d	rdmsr
000000000000992f	movq	%rdx,%rcx
0000000000009932	shlq	$0x20,%rcx
0000000000009936	movq	%rax,%rdx
0000000000009939	andl	$0xf8ff7ff8,%edx
000000000000993f	orq	%rcx,%rdx
0000000000009942	orq	$0x01000007,%rdx
0000000000009949	movl	$0x000000e2,%ecx
000000000000994e	movq	%rdx,%rax
0000000000009951	andl	$0xff,%eax
0000000000009954	shrq	$0x20,%rdx
0000000000009958	wrmsr

[flAked]

Changing that 'add' is a bit tricky, because we need a new opcode for the instruction.

 

My proposition is to nop out the wrmsr where ecx=0x2E. If we need to configure something, we can do it in RevoBoot or leave the setting from the bios.

 

BTW; I used otx, my addresses seem to differ.

[Time2Retire]

Changing that 'add' is a bit tricky, because we need a new opcode for the instruction.

 

My proposition is to nop out the wrmsr where ecx=0x2E. If we need to configure something, we can do it in RevoBoot or leave the setting from the bios.

I would like to start by locating the panic first. Then see where else it panics. On a second thought. That if we try that first? To see if P-States are working? Do you have a single line script for this?

 

BTW; I used otx, my addresses seem to differ.

Yeah. Different OS X versions. Have otx as well. Cool tool.

[flAked]

I would like to start by locating the panic first. Then see where else it panics. On a second thought. That if we try that first? To see if P-States are working? Do you have a single line script for this?

All manual labour at this point

 

The problem is, I patched all 10 places where ECX is set directly before the wrmsr and it still panics on E2, that means there is a wrmsr somewhere where ECX is set indirectly.

 

Replacing all wrmsr works here as well.

[Time2Retire]

All manual labour at this point

 

The problem is, I patched all 10 places where ECX is set directly before the wrmsr and it still panics on E2, that means there is a wrmsr somewhere where ECX is set indirectly.

 

Replacing all wrmsr works here as well.

Well. Tomorrow another day. Need to get to bed now. Sweet dreams

[ThisName]

Thanks so much guys! This is very exciting.

 

Will there be a version for the P8P67 PRO? Also, how will this relate to Z68 boards?

[flAked]

Basically, it will be universal for every Motherboard that has this "bug". But as we only have P8-boards to test this on, it will mainly be for P8*. The Z* variant is in essence the same platform without some restrictions, so I would guess nothing will change much in terms of the BIOS.

 

I will probably make a patcher for it, once we figured everything out.

 

 

UPDATE: it works! After a recent coffeine injection and checking all 130 instances of wrmsr I realized that I only patched the 32bit version. So patching those 10 wrmsr where ecx=0xe2 works. I manually checked the surrounded code and it shouldn't affect anything else.

[Time2Retire]

UPDATE: it works! After a recent coffeine injection and checking all 130 instances of wrmsr I realized that I only patched the 32bit version. So patching those 10 wrmsr where ecx=0xe2 works. I manually checked the surrounded code and it shouldn't affect anything else.

This is great, but now we must put pressure on Asus. We must tell them to fix this, and that not doing so will hurt sales because we have to say buy GigaByte instead.

 

I tell you this. There is absolutely noting in the Intel datasheets, nor the BIOS writers guide for that matter, that tells you to lock that bit (15). What they do with this is to drive people into buying a 300 Euro motherboard instead of a mainstream one that is far less expensive. But the minute I know Asus isn't willing to cooperate, and that their 300 Euro piece of art (ASUS Maximus IV Extreme Republic of Gamers) works... I am ordering one!

 

Anyone here with a non Yahoo, Google or Hotmail (blocked in that forum) should join you there and make noise. Tell them that the *nix world want their piece of the action. Or we should at least get a quick reply with an explanation as to why they lock this bit. Not to mention that they need to change the manual because disabling C-States in the BIOS isn't really disabling them. Only changes the ACPI tables.

 

Think about it. Are we willing to go through all this yet again with every update? I sure don't. I want a vanilla solution. Not a half baked one so thank you very much Asus.

 

p.s. I can only find 68 wrmsr's in the 10.6.8 version but that is probably only the 32-bit version of the code.

 

Do you have an e-mail address of him. If not can you ask it for me as I cannot join you there.

[flAked]

I'm fully with you on this! You could make an anonymous email at hushmail.com - that will work for the forum registration. I only pm'ed him (so no email).

 

One simple test in Linux should show their buggy C-state code clearly. How do I get C-state status in Linux?

Found this tool, shows C0, C3, C6 even if disabled: http://code.google.com/p/i7z/

 

 

In the meantime, I made a patcher, so we can work on refining our DSDT/SSDTs. I won't release it just yet, needs some testing.

[Time2Retire]

I'm fully with you on this! You could make an anonymous email at hushmail.com - that will work for the forum registration. I only pm'ed him (so no email).

Done. Waiting for activation e-mail...

 

One simple test in Linux should show their buggy C-state code clearly. How do I get C-state status in Linux?

Found this tool, shows C0, C3, C6 even if disabled: http://code.google.com/p/i7z/

Yeah I know. They only remove some ACPI table data. Stupid but true.

 

In the meantime, I made a patcher, so we can work on refining our DSDT/SSDTs. I won't release it just yet, needs some testing.

Thanks. Will have a go with it, but how do we check that P-States are actually working? I don't want to install istat as that slows down the boot process too much. Or maybe I should and remove it afterwards?

 

Do you have FakeSMC plug-ins loaded and if yes, which onces?

[flAked]

Done. Waiting for activation e-mail...

Posted over there, have a look.

 

Do you have FakeSMC plug-ins loaded and if yes, which onces?

Only IntelCPUMonitor.

 

 

With the patch and a loaded AICPUPM I get terrible screen-flicker. If I load Injector.kext it goes away, but still doesn't look as smooth (my eyes might have fooled me...). If I patch out all wrmsr the screen looks totally fine.

[Time2Retire]

Posted over there, have a look.

Thanks. And now we wait, again.

 

Only IntelCPUMonitor.

And what does this give you? Only CPU temperature readout I guess.

 

With the patch and a loaded AICPUPM I get terrible screen-flicker. If I load Injector.kext it goes away, but still doesn't look as smooth (my eyes might have fooled me...). If I patch out all wrmsr the screen looks totally fine.

What is your FSBFrequency before and after Injector.kext loads?

 

I patched the 10.6.8 kext and got this:

SpeedStepper v1.0 - © flAked 2011
for AICPUPM v142.6.0

Searching for wrmsr #0: 34a46
-> found bytes.
-> patched.

Searching for wrmsr #1: 34d3e
-> found bytes.
-> patched.

Searching for wrmsr #2: 34d5f
-> found bytes.
-> patched.

Searching for wrmsr #3: 34f03
-> found bytes.
-> patched.

Searching for wrmsr #4: 34fa2
-> found bytes.
-> patched.

Searching for wrmsr #5: 35f27
-> found bytes.
-> patched.

Searching for wrmsr #6: 3617c
-> found bytes.
-> patched.

Searching for wrmsr #7: 361ce
-> found bytes.
-> patched.

Searching for wrmsr #8: 3d61a
-> found bytes.
-> patched.

Searching for wrmsr #9: 3d677
-> found bytes.
-> patched.

Searching for wrmsr #0: 948e
-> found bytes.
-> patched.

Searching for wrmsr #1: 98c1
-> found bytes.
-> patched.

Searching for wrmsr #2: 997e
-> found bytes.
-> patched.

Searching for wrmsr #3: 99eb
-> found bytes.
-> patched.

Searching for wrmsr #4: 9aae
-> found bytes.
-> patched.

Searching for wrmsr #5: a958
-> found bytes.
-> patched.

Searching for wrmsr #6: abff
-> found bytes.
-> patched.

Searching for wrmsr #7: ac96
-> found bytes.
-> patched.

Searching for wrmsr #8: 11d0e
-> found bytes.
-> patched.

Searching for wrmsr #9: 11dc2
-> found bytes.
-> patched.

All done. Bye 

No screen flicker. Remove ssdt_pr.aml and reboot to check if that stops the screen flickering, in which case you PR objects are not ok.

 

What are you using btw?

 

Download the source code of AppleSMBIOS and comments out the FSB quad pump line:

busSpeedMTs *= 4;  // Assume quad-pumped FSB

In AppleSMBIOS.cpp

 

Also. Anyone here who know how to read this 1999 turbo ratios thing?

 

Update: I do. This is the turbo ratio for the cores (based on the active number of cores) and this should (normally) output 1234 (see blow):

 

For the i7-2600(K) this results in (no OC):

3.5GHz for when all cores active.

3.6GHz for when three cores are active.

3.7GHz for when two cores are active

3.8Ghz for when one core is active.

 

And for the i7-2500(K) this results in (no OC):

3.4GHz for when all cores active.

3.5GHz for when three cores are active.

3.6GHz for when two cores are active

3.7Ghz for when one core is active.

 

However. Setting the UEFI BIOS to AUTO does not work properly! Please take note of this:

 

1.) Select the: "Ai Tweaker" menu.

 

2.) Select: "Maximum Turbo Ratio setting in BIOS"

 

3.) Set all four multiplier fields to either (i5-2500K) 34, 35, 36 and 37 / (i7-2600K) 35, 36, 37 and 38 or "Auto".

 

4.) Set Turbo Ratio to: "Auto"

[flAked]

And what does this give you? Only CPU temperature readout I guess.

Yep.

 

What is your FSBFrequency before and after Injector.kext loads?

Hmm, I can't reproduce the flicker anymore, don't know what's going on. I get around 100328735 now, without Injector. That's the case for NullCPU, AICPU with 10 nops or all nops.

 

What are you using btw?

You mean for the patcher? That's homemade C code.

[Time2Retire]

You mean for the patcher? That's homemade C code.

No ssdt_pr.dsl Time to team up and get things working, no?

 

Does sleep work for you? It did when I changed all of them, but now it restarts. Well almost because it is stuck. False alarm. Sleep only fails with the factory DSDT (which is what I was testing).

[flAked]

This is my current, I believe it's incomplete because the other CPU's are missing aliases.

 

ssdt_pr_minimal.dsl.zip

 

 

Going by the list: http://www.insanelymac.com/forum/index.php...t&p=1681444

Not sure what we should use for PCT?

 

Ahh, now I get it. Sleep works, but upon wake the flickering starts.

[Time2Retire]

This is my current, I believe it's incomplete because the other CPU's are missing aliases.

 

ssdt_pr_minimal.dsl.zip

 

Going by the list: http://www.insanelymac.com/forum/index.php...t&p=1681444

Not sure what we should use for PCT?

 

Ahh, now I get it. Sleep works, but upon wake the flickering starts.

Sorry. Don't understand. What exactly do you mean with this 'screen flickering'?

 

Note: I am using iMac12,2 as model identifier, and I patched the AGPM iMac12_2.plist so that the device-id matches with my Radeon HD 6850. Might this be the problem - maybe you didn't do this?

 

Sorry. Hockey training now. Will be back later...

[flAked]

Sorry. Don't understand. What exactly do you mean with this 'screen flickering'?

It's the same effect I get when connecting my monitor through DVI. That was the reason for me to buy a HDMI-DVI cable. It flickers most notable on constant grey areas. Like in the old days, when your monitor was running the wrong frequency.

 

Note: I am using iMac12,2 as model identifier, and I patched the AGPM iMac12_2.plist so that the device-id matches with my Radeon HD 6850. Might this be the problem - maybe you didn't do this?

I'm using iMac12,3 any reason for the iMac12,2?

 

And yes, AGPM could be the problem. I'm missing the current version that has the iMac12 definition.

 

 

I do get the correct Turbo values, but ACPI_SMC_Platform is timing out:

AppleIntelCPUPowerManagement: Turbo Ratios 1234
ACPI_SMC_PlatformPlugin::start - waitForService(resourceMatching(AppleIntelCPUPowerManagement) timed out

[ThisName]

This is great, but now we must put pressure on Asus. We must tell them to fix this, and that not doing so will hurt sales because we have to say buy GigaByte instead.

 

I tell you this. There is absolutely noting in the Intel datasheets, nor the BIOS writers guide for that matter, that tells you to lock that bit (15). What they do with this is to drive people into buying a 300 Euro motherboard instead of a mainstream one that is far less expensive

 

...

 

Anyone here with a non Yahoo, Google or Hotmail (blocked in that forum) should join you there and make noise. Tell them that the *nix world want their piece of the action. Or we should at least get a quick reply with an explanation as to why they lock this bit.

 

I'm with you. Let us know what we can do to put some pressure on. I also suggest posting specifically what you said above (or at least threatening to) in places like Tonymac which has a pretty big influence on buying decisions.

...