Jump to content

DSDT for Asus P8P67-M PRO

Time2Retire

By Time2Retire,
in Patches

 Share
834 posts in this topic

Recommended Posts

flAked
flAked
Posted
Posted

Can you test if this is the same case with the modded BIOS (vs. the patched AICPUPM)?

I can confirm that my system won't wake up with these Turbo Ratios. I hear a quick respin of the HDDs however, so it is reacting on my USB keyboard, but can't complete the wake.

 

Something different, as I'm preparing my thread, did I miss something we did?

1) RevoBoot with iMac12,2 definition

2) SpeedStepper or BIOS mod

3) custom DSDT/SSDT

4) iMac12_2.plist for AMC_PP from 10.6.8 update

5) Intel6SeriesAHCI injection in FakeSMC

6) SMBIOS fix

Link to comment
Share on other sites
mrmojorisin17
mrmojorisin17
Posted
Posted
Can you test if this is the same case with the modded BIOS (vs. the patched AICPUPM)?

I can confirm that my system won't wake up with these Turbo Ratios. I hear a quick respin of the HDDs however, so it is reacting on my USB keyboard, but can't complete the wake.

Now I made the test with 0713 modded BIOS.

Later I'll make the same tests with original 0713 BIOS version and patched AICPUPM.kext.

Link to comment
Share on other sites
mrmojorisin17
mrmojorisin17
Posted
Posted
Something different, as I'm preparing my thread, did I miss something we did?

1) RevoBoot with iMac12,2 definition

2) SpeedStepper or BIOS mod

3) custom DSDT/SSDT

4) iMac12_2.plist for AMC_PP from 10.6.8 update

5) Intel6SeriesAHCI injection in FakeSMC

6) SMBIOS fix

It seems to be ok.

You're ever in time to add something later :(

Link to comment
Share on other sites
mrmojorisin17
mrmojorisin17
Posted
Posted

Strange that wake problem comes only with Turbo Ratios 89AB and not with Turbo Ratios 1234 :(

Not so strange really...

I read many times that people with OC'ed CPU had problem with sleep/wake and also with SpeedStep that doesn't work in extreme OC.

I don't know if 4,4GHz could be named like an extreme OC...

 

EDIT

Problem solved.

I just disabled Internal PLL Overvoltage and now seelp/wake works correctly also with Turbo Ratios 89AB :(

Link to comment
Share on other sites
bdv
bdv
Posted
Posted
This seems to me like only the turbo states are working.

 

I launched Cinebench just after loading MSRDumper.

After several minutes with differnt apps running, I got:

 

Jun  7 13:29:59 P8Z68-VPRO kernel[0]: MSRDumper CoreMulti(35)                                                                                         
Jun  7 13:29:59 P8Z68-VPRO kernel[0]: MSRDumper PStatesReached: 16 23 28 35 36 37                                                                     
Jun  7 13:29:59 P8Z68-VPRO kernel[0]: MSRDumper CoreMulti(35)                                                                                         
Jun  7 13:29:59 P8Z68-VPRO kernel[0]: MSRDumper PStatesReached: 16 23 28 35 36 37                                                                     
Jun  7 13:30:00 P8Z68-VPRO kernel[0]: MSRDumper CoreMulti(35)                                                                                         
Jun  7 13:30:00 P8Z68-VPRO kernel[0]: MSRDumper PStatesReached: 16 23 28 35 36 37                                                                     
Jun  7 13:30:00 P8Z68-VPRO kernel[0]: MSRDumper CoreMulti(35)                                                                                         
Jun  7 13:30:00 P8Z68-VPRO kernel[0]: MSRDumper PStatesReached: 16 23 28 35 36 37

 

Seems better.

Link to comment
Share on other sites
mrmojorisin17
mrmojorisin17
Posted
Posted

I've this option here on my BIOS

 

110607163727.png

 

Have you tried to install new version (rev 493) of FakeSMC and his PlugIns?

I tried but I get a sound assertion that break my audio:

Sound assertion "0 == layouts" failed in  "/SourceCache/AppleHDA/AppleHDA-199.4.12/AppleHDA/AppleHDADriver.cpp" at  line 807 goto Exit

I'm returned to IntelCPUMonitor (rev 483) and NVClockX (rev 477) that works without problems.

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Have you tried to install new version (rev 493) of FakeSMC and his PlugIns?

Works without problems here. But I don't use the onboard sound so I can't say...

 

Thanks for the BIOS tip, sleep works once again.

Link to comment
Share on other sites
neogeo
neogeo
Posted
Posted

Trying to digest this thread as best I can. I am just starting out with a build based on this board. Will there be a step by step guide on setting this up with revoboot? Would love to get this working but kinda lost at the moment...

Link to comment
Share on other sites
buoo
buoo
Posted
Posted

Excuse me flAked

 

Do the values those we add in CPU/STATIC_DATA.C complete the job that the SSDT does to get the speedstep working? I mean.... if I don't add these values does the speedstep work in the same way ?

Looking around I could see that several users have a no complete working (9 different p-states, like you).

Probably they use Chameleon which doesn't allow to insert these values.

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Can you make a test with onboard sound active?

Do you know where I can find AppleHDA source code?

Are you kidding me? After all the work that you and DHP had made it was the least I could do!

Sound is active at the moment, but I get assertions anyways, because I didn't patch AppleHDA, which is closed source btw. Otherwise we wouldn't need to bin-patch it.

 

Oh, well. I'm still grateful if people are doing experiments on their own, I constantly get angry at the "everything gets fixed for you" attitude.

 

Will there be a step by step guide on setting this up with revoboot? Would love to get this working but kinda lost at the moment...

I'll include a quick rundown of the important RevoBoot settings, yes.

 

Do the values those we add in CPU/STATIC_DATA.C complete the job that the SSDT does to get the speedstep working?

You can use either the static or dynamic CPU detection in RevoBoot, it's just a speedup to the boot process.

 

The last time I checked the Chimera code there were still bugs for SandyBridge (wrong busspeed for example). RevoBoot was extended/developed to set up things correctly for SB.

 

And no, the CPU data is just for basic setup, the SSDT_PR includes the necessary P-State information.

Link to comment
Share on other sites
mrmojorisin17
mrmojorisin17
Posted
Posted
Sound is active at the moment, but I get assertions anyways, because I didn't patch AppleHDA, which is closed source btw. Otherwise we wouldn't need to bin-patch it.

Ok, thanks. I'll make some other test when someone'll reply @ my post to ProjectOSX.

Oh, well. I'm still grateful if people are doing experiments on their own, I constantly get angry at the "everything gets fixed for you" attitude.

I like to make test because is a method to learn something new.

Naturally for things that don't require development knowledges ;)

Link to comment
Share on other sites
mrmojorisin17
mrmojorisin17
Posted
Posted

Yep, I've seen it :(

I think that the sound assertion that comes out in kernel.log depends on something on AppleHDADriver.cpp, so I asked you if you know where to get AppleHDA source code.

Or maybe it depends to something else in NVClockX code... I don't know :wacko:

 

For sure sound assertion depends to NVClockX (I don't think it depends to IntelCPUMonitor) because the errors in kernel.log appears after upgrading this PlugIn!

 

But from what in particular?

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Hei flaked could you verify the validity of this ssdt_pr for 2600k ?

Looks good. Have you changed anything? This looks like the standard SSDT_PR for 2600K.

 

For sure sound assertion depends to NVClockX (I don't think it depends to IntelCPUMonitor) because the errors in kernel.log appears after upgrading this PlugIn!

They have changed a lot in the NVClockX code, but I don't have the time to look into it.

 

I suggest posting this issue @projectosx in the FakeSMC thread.

Link to comment
Share on other sites
mrmojorisin17
mrmojorisin17
Posted
Posted
They have changed a lot in the NVClockX code, but I don't have the time to look into it.

 

I suggest posting this issue @projectosx in the FakeSMC thread.

I posted and explained my issue yesterday but for the moment I get no-response.

I take a look at NVClockX code but I didn't find anything related to a possible sound assertion, surely because I don't know where I have to look exactly.

 

Any news regarding chipset? Is there a possibility to get correct info showed in System Profiler without plist injection in FakeSMC?

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
Any news regarding chipset? Is there a possibility to get correct info showed in System Profiler without plist injection in FakeSMC?

Either by using DSM (which is slow), making a dummy kext (so you haven't have to worry about FakeSMC updates) or the EFI injecting discussed here

 

EFI injection is favored, but as discussed in the thread I wasn't able to manually generate the injection data for my GFX.

Link to comment
Share on other sites
mrmojorisin17
mrmojorisin17
Posted
Posted

Sorry, maybe I explained in a bad way.

I know that instead of injection plist I can use a method _DSM in DSDT or a dummy kext ;)

I just want to know if there is a method to get chipset perfectly recognized in a Vanilla way, only with AppleAHCPort that contains the id of our chipset.

EFI injection is favored, but as discussed in the thread I wasn't able to manually generate the injection data for my GFX.

What are you using at the moment to get VGA working? Graphics Enabler? Or something else?

You can try to get your current VGA injection with Lizard and compare the plist-out with the one that you've created.

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
I just want to know if there is a method to get chipset perfectly recognized in a Vanilla way, only with AppleAHCPort that contains the id of our chipset.

Does it work if you delete Item1 in the AppleAHCIPort plist?

 

Looking at the iMac12,2 ACPI tables 1C,2 is actually the firewire device. That must mean that the SATA device is at 1C,3 and getting matched on that address. If we look at the device definitions there is actually no RP04 device defined, which would have the 1C,3 address.

 

In our DSDT we do have this:

Device (RP03) // Renamed from: PEX2
{
Alias (AR13, _PRT) //changed from AR12
Alias (PW94, _PRW)
Name (_ADR, 0x001C0002)
}

So the device gets matched twice. Let's try and remove that.

 

That didn't change anything. Now let's remove Item1. That didn't change anything, either.

 

We have the identical plist definition and still no match. That can only mean that the kext probe() function is checking for more (IRQs?) where the dummy kext is just matching without probing.

Link to comment
Share on other sites
flAked
flAked
Posted
Posted
What are you using at the moment to get VGA working? Graphics Enabler? Or something else?

You can try to get your current VGA injection with Lizard and compare the plist-out with the one that you've created.

Oh wow, that is very cool. It's actually doing what I was trying to figure out, getting the current injection, sweet ;)

I'm currently using static injection data that I got from booting Chameleon with GraphicEnabler and the efi2struct tool.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...