Contribute
Register

Intel DH77DF Motherboard

Status
Not open for further replies.
So which one of these DSDT's should I use?

Does the Sleep-Wake-USB3 DSDT do everything the Sleep-Wake-RTC-EHC DSDT does?
 
I was about the ask the same question Flavio !

Also, what is the difference between the .asl format and the .dsl file format ? I think MultiBeast expects a dsdt.aml file to be on the desktop. I think my DSDT editor can convert / compile between some types....
 
Just go with the USB3 version. I removed the older dsdt. New one has some devices names changed in line with MacBook Pro Retina dsdt, e.g. SAT0 is now SATA, XHCI is XHC1 and description of SAT1 is removed.

Load the file in your favorite dsdt editor, compile it and save aml file in /Extra, that's it.
 
I tested both of them and the USB version is the better one I think. With the USB one my Logitech MX Revolution mouse is still active after Wake.
BTW Wake is possible by power button, keyboard or mouse.

I am gonna try my USB3 ports tomorrow.

With regard to the file names, I just put them in /Extra/ and renamed the one I want to use to DSDT. The suffix doesn't seem to matter, both .asl and .sml seem to be recognized and loaded.

One other question, if I use the DSDT, what options in MultiBeast can I leave unchecked?
 
I still can't make my mouse and keyboard to wake the PC, but I had the suspicion that it should work without a problem. Would you mind sharing your BIOS version and configuration options?

Also, what is your current multibeast configuration? What about AppleIntelCPUPowerManagement? Are you using the original one, the patched one or NullCPUPowerManagement? For now my system works with the 10.7.4 patched AICPM, but would prefer to use the Mountain Lion one, even if the patched version. I want to be as close to vanilla installation as possible.

As for other options - for now I'm not sure if it is possible to use the unmodified AppleHDA driver, but the modified one works without the HDAEnabler. Also ethernet still requires the custom driver, but maybe some additional fixes would take care of that as well - I don't know what conditions must be met for the Apple drivers to support the 82579V. For now, hnak's driver saves the day.

You can leave out restart/shutdown fix (EvOreboot) and RTC clear (AppleRTC patch or force legacy RTC) fixes. IOAHCIBlockStorageInjector is also unnecessary (I think. I made the storage internal, but haven't tried without it yet after my DSDT edits). FakeSMC is still required though, since it's faking a custom SMC chip that's present only on Intel Mac motherboards.

And I'm surprised that chameleon just loads the uncompiled file. Are you sure you just took the one that I attached and shoved it into /Extra, and it works? That would be nice.
 
Here are my BIOS settings.

39747-bios-version.jpg


39748-usb-settings.jpg


39749-power-settings.jpg

My Extra/Extensions folder is empty.
In S/L/E my AppleIntelCPUPowerManagement.kext is from 31 May 2012.
I have no NullCPUPowerManagement.kext.
For Audio I use the ALC898 Driver Without DSDT from MultiBeast 5.1.0.
For Ethernet I use the hnak's AppleIntelE1000 Driver from MultiBeast 5.1.0.

I extracted the file from the ZIP and renamed it DSDT.asl and it is loaded automatically, no need to change org.chameleon.Boot.plist.

This is my org.chameleon.Boot.plist. What entries could I delete safely?

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>EthernetBuiltIn</key>
<string>Yes</string>
<key>GenerateCStates</key>
<string>Yes</string>
<key>GeneratePStates</key>
<string>Yes</string>
<key>AtiConfig</key>
<string>Eulemur</string>
<key>GraphicsEnabler</key>
<string>Yes</string>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string>darkwake=0 PCIRootUID=1</string>
<key>Legacy Logo</key>
<string>Yes</string>
<key>Timeout</key>
<string>2</string>
<key>UseKernelCache</key>
<string>Yes</string>
<key>device-properties</key>
<string>7f0000000100000001000000730000000200000002010c00d041030a000000000101060000027fff04002c0000004100410050004c002c00690067002d0070006c006100740066006f0072006d002d006900640000000800000005006201140000006800640061002d0067006600780000000d0000006f6e626f6172642d31</string>
</dict>
</plist>

There is still one little quirk. After reboot if I choose Sleep from the Apple Menu the Mac goes to sleep but wakes up again immediately without any input. If I choose Sleep again after that it stays asleep?
 
Last edited by a moderator:
I did some further testing and to my surprise Sleep/Wake also works on my system without the DSDT?
The only thing different is that Wake by Mouse doesn't work, only Power Button or Keyboard Wake functions.
 
What's the wake reason when machine wakes up immediately?

RE: No DSDT - that's even more interesting. ;) That may be because of your old bios. I have latest Intel BIOS and only basics work without the DSDT tweaks. Maybe the machine even sleeps, but then it wakes up immediately, every time.

Your org.chameleon.Boot.plist file can be reduced to this I think:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>AtiConfig</key>
<string>Eulemur</string>
<key>GraphicsEnabler</key>
<string>Yes</string>
<key>Kernel Flags</key>
<string>darkwake=0 PCIRootUID=1</string>
<key>Legacy Logo</key>
<string>Yes</string>
<key>Timeout</key>
<string>2</string>
<key>device-properties</key>
<string>7f0000000100000001000000730000000200000002010c00d041030a000000000101060000027fff04002c0000004100410050004c002c00690067002d0070006c006100740066006f0072006d002d006900640000000800000005006201140000006800640061002d0067006600780000000d0000006f6e626f6172642d31</string>
</dict>
</plist>

But you'd have to check with MSRDumper if at least the P-States are generated without the chameleon options.

Ethernet is configured as built-in in DSDT, so no need for that option. You're loading the default kernel anyway, so no need for that switch as well, just like using kernel cache - it's yes by default.
 
Yeah, but you can look in logs using the Console, what actually was the wake reason. There should be a line similar to

Nov 30 10:23:56 mini kernel[0]: Wake reason: XHC1
 
Status
Not open for further replies.
Back
Top