10.9 on Z68: sleep or audio, not both!

[Nodarkthings]

Hi!
I'm the happy owner of a nearly one year old Z68XP-UD3 based machine (see my signature) with "dual" boot 10.6.8 and 10.8.x on the same disk.
As far as I've arrived with my trials on Mavericks (on a second hard disk ), I must chose between sleep and audio as it needs npci=0x3000 to have sleep/wake working, but this setting is known, as mentioned here to break audio!
Just in case, I've tried npci=0x4000, but it behaves as if I don't use the flag at all (i.e. the machine keeps running without KB/mouse/screen on and isn't able to wake up, even with the power switch).
Except for that and some app/prefpane/extension not working anymore (but this was expected), it seems pretty slick though my test disk is an old Sata I.
Anybody having ideas of whether there is a solution or not?
Thanks.

 

[Nodarkthings]

Funny enough! Just when I finished my precedent post, I tried to put the computer to sleep from my usually perfectly working 10.6.8 partition and it behaved exactly like it did on the 10.9 test disk! (no complete sleep, no wake up)
It obviously came to my mind that the two disks were interfering in some way.
So I've just started 10.9 with my usual disk unplugged and npci=0x4000.
Oh yeah! Audio AND sleep working!

In conclusion, if it may help someone else, here are my working settings for my machine under 10.9 with F10 DSDT:
<key>EthernetBuiltIn</key>
<string>Yes</string>
<key>GenerateCStates</key>
<string>Yes</string>
<key>GeneratePStates</key>
<string>Yes</string>
<key>GraphicsEnabler</key>
<string>Yes</string>
<key>Kernel</key>
<string>mach_kernel</string>
<key>Kernel Flags</key>
<string>darkwake=0 PCIRootUID=1 npci=0x4000</string>
<key>Legacy Logo</key>
<string>Yes</string>
<key>Timeout</key>
<string>2</string>
<key>UseKernelCache</key>
<string>Yes</string>

IMPORTANT EDIT: to sum up what has been said later in this thread, all is working with darkwake=0 and without any npci setting!!!
=> and use AppleRTC patch in MB 6.x to avoid CMOS errors on boot!!!

Note that the Chimera version is important, here's just what I've noticed:
- my 10.6.8 partition won't start if the active Chimera boot is the one on the other disk and above 2.0.1
- my 10.9 disk won't start if its Chimera boot is 2.0.1 or below
(tip: to switch Chimera boot on start, press the F12 key then select the right disk)

EDIT: 10.6.8 and 10.9 can be put on one single disk with Chimera version 2.2.1 but you'll need a precise strategy to have both audio and sleep on both OSes... (see the EDITs at the end of my build description for more details)

 

[UtterDisbelief]

Good work!

I'll keep watching this one.

I haven't had sleep working since 10.8.3 and I have a Z68 board so this is giving me a glimmer of hope

 

[Nodarkthings]

So glad if I can help you !
Well, on my 10.8.3 partition, I've got the same settings except for npci=0x3000 and sleep is working: do you mean that you had it working on 10.8.3 and not after or not even on 10.8.3?
(by the way, npci=0x3000 is compatible with 10.6.8, that's how I've got SL and ML working on the same disk )

About my craze for dual boot: I've just tried 10.6.8 and 10.9 on one single disk with Chimera 2.2.1, but unfortunately not very convincing: yes it starts and works ok on both, but no more sleep on 10.9 as it uses (at least some of) the information in the first partition (boot? Extra?) — I've tried npci=0x4000 in the first partition (10.6.8)'s org.chameleon.Boot.plist but 10.6.8 stopped starting after the dreaded "PCI configuration begins"... And no more sleep on 10.9, neither shutting down correctly... :
I suppose something's got messed up in the BIOS.

 

[UtterDisbelief]

Yes everything works in 10.8.3 - but not later versions.

Very recently I have been suffering from CMOS resets after sleep and reboot in 10.9. I installed the patched RTC kext from MultiBeast 6 and this stopped the problem BUT it didn't help wake-from-sleep.

Today I will try your settings (above) and report back on any improvements!

 

[Nodarkthings]

You just gave me 2 precious news (not to update my ML partition and patched RTC).
Would UEFI help?

Hey! I've just bumped on that: http://www.tonymacx86.com/dsdt/100182-pjalms-dsdt-patches.html
Quite interesting, did you know about that?

 

[UtterDisbelief]

Good find

Sadly my motherboard - Z68AP - is not one of those listed and doesn't have a UEFI - just old-fashioned BIOS.

Also I am wary of modifying the DSDT if I can avoid it.

My reason is because back in 10.8.3 there were no problems regarding wake-from-sleep or USB.

I would always want to know what it is that the DSDT edit is doing before I apply one.

As you say though, very interesting!!

 

[Nodarkthings]

Bad news, here: I've lost sleep on any of my ex-perfectly-working-partitions, even with my 10.9 test disk unplugged!
I've tried resetting the bios to one of my saved presets, reinstalling Chimera boot 2.0.1, starting with -x: no way! :
Finally it worked loading bios "optimized default" and its basic bios settings!

 

[Nodarkthings]

If I understand well PJALM's thread, it's up to us to submit our native DSDT through some utility and he can patch it and add it to the repository, or not?
I must say that if I could have my Firewire port working correctly, that wouldn't be bad...

 

[UtterDisbelief]

Well I had a busy day and tried a *lot* of different settings to try and cure the lack of sleep!!!

Firstly I removed the USB3 and Ethernet kexts. Then I rebooted.

Still no wake-from-sleep.

The only other kexts I use are AppleHDA as modified by Toleda for ALC889 and a small code injection to recognise my wi-fi card. Removing audio .... Still no wake!

I tried several different machine definitions (which was actually fun!) but these made no difference either.

Also tried a few npci= settings. No joy.

I am coming to the conclusion that you are correct - a modification to the DSDT might be the only cure.

I did spend some time reading the spec for ACPI and the Apple kext, as this is where the DSDT is used and then tried using the kext from 10.8.3 thinking that because it worked before maybe it will work again now.

No.