Jump to content
47 posts in this topic

Recommended Posts

Cool, well done. Did you use DarkWake 0 or No (just out of interest)

 

I can give you the sleep enabler I use but I use it on 10.6.8. My atom is an n270 so is only 32 bit and won't reliable run lion. It's actually my girlfriends netbook so don't want it crashing on her all the time because she'll only moan...more!

  • Like 1

DarkWake=0.

 

Thank you for the answer, James. I'm afraid the dsdt patching patch is the only left. But there's one last question before starting to patch: I did remove NullCPUPowerManagement indeed, as well as AppleIntelPowerManagement. But i left alone the kext AppleIntelPowerManagementClient, since it appears to do no harm. Could it have something to do with the lack of sleeping capability in my Atom netbook?

 

Thanks!

  • 1 month later...

After a month trying to patch my dsdt so sleep works in my Atom netbook, still no joy...

 

 

I successfully dealt with those errors of the last post of mine, which used to prevent me from effectively compile my patches. Oldnapalm point me the solution for it: i had to add DTGP patch, so i did it and finally compiled my first patched dsdt. The problem is that the patch that supposedly could grant my computer sleep/speedstep capabilities simply showed no result. Better saying, gave me a kernel panic (ACPI, non-supported CPU) when i removed nullCPUpowermanagement.kext and sleepenabler.kext. from S/L/E/. I tried other related patches to no avail.

 

 

In the meantime, i tried some "conservative" fixes for sleep/speedstep: VodooPowerMini (no result), a lot of sleep enablers (including the newest, sleepenableruniversal.kext), using the sleep enablers with the couple NullCPU, AppleCPU, with Voodoo alone, with voodoo+AppleCPU+NullCPU. Tried an heterodox fix i found in the Clover development thread (altering some info in the IOfamily kext plugin for the model of Mac my smBIOS assigned to my netbook). Any combination of those tries and fixes either didn't change a iota or messed with my system altogether.

 

 

I should've thrown the towel, but i'm not the one giving up here, so i return to dsdt, but still no positive results. Can someone take a look at my "virgin" dsdt, so to advise me on possible solutions for my problem? I'm not lazy and i'm not wanting nobody to do my job, but any light on the issue would help me a lot, because i'm simply stuck with this problem. Tried the ICH7 fix with and without the "conservative" methods above, but made no advances.

 

 

I uploaded my unedited dsdt.aml. Thank you for any bit of advice.

 

Hi, eeep! Thank you for answering me!

 

You're asking me about any of my dsdt attempts to use native power management? No, i didn't, since i was already in Mountain Lion when started to patch my dsdt. In fact, i'm using an APCI rollback (from 10.8.0) since i updated the system to 10.8.2, but this rollback, i think, is needed for all hackintoshes, right?

 

However, you may be asking about my "conservative" attempts, using legacy kexts, when i was running Lion. No, i didn't roll back. I tried all those legacy kexts in Mountain Lion, too, to no avail. Should i give a shot to the combination of legacy kexts/Snow Leo ACPI rollback with Mountain Lion? If it's the case, what's the combination of kexts do you advise me?

 

Should i try it? Could it be compatible with ML anyhow?

 

Thank you very much indeed, eeep!

Here, try this one AppleACPIPlatform.kext.zip , not needed on all 10.8 hackintosh, but quite a few. Since your using AMD and Atom it may or may not help, but might work better with patched kernel and shouldn't cause any problems to try.

  • Like 1

Downloaded it, eeep: thank you very much! Now, what do i do? Use it together with sleep enabler? Or with voodoopowermini? Both? Or i patch my dsdt again with ich7 fix and i'll have native power management? Sorry so many questions, but i'm really lost here.

 

P.S.: i have already an ACPI rollback in my Atom 10.8.2 hackbook: that rollback was necessary because of a change in the kernel that made it have incompatibilities with fakeSMC (more precisely, osmBIOS.kext). Will this older kext be a good replacement to the one already have, with the plus of enabling native power management?

 

Thank you, eeep! Much appreciated, really!

You would simply replace the one that's there. It's an older one from SL which is needed to fix ML for many users, where trying to use ones from Lion don't seem to work. So maybe it also help you to use that older one as well instead of one from Lion. So just rolling it back a bit further than you already have is all.

  • Like 1

Thanks, eeep!

 

In fact, the one i'm using is the one uploaded by the user unixservice in the topic "10.8.2 Final (C54)". With that ACPI kext, my system is already running very smoothly, except for the annoying sleep issues and another one related to restart/reboot. That's why i made so many questions: i must confess that i'm afraid to mess my whole system just by trying to fix sleep. But i think i'll just give it a try. :)

 

Thanks again!

Looks like that one is new version patched to fix boot issues. You may have better luck with the older one, and you may not see any difference. Only one way to know. If by chance you ever install a kext that prevent's booting, be it now or in the years to come, and don't have a way to access the HD, as long as you make backup copies of replaced kext first, you can switch them back either from single user mode or if that won't work, from terminal in the installer then reboot with -f so cached version doesn't try to load still.

Thanks again, eeep!

 

In fact i think i'm very well prepared for this possibility, and it was thanks to it that i managed to make so much experiences and troubleshooting until this day: i have a full installation of Mountain Lion 10.8 in a 16GB USB stick. Slow as hell, takes an eternity to start up, but has, besides a working 10.8 running with the first 12.0 patched by meklort, also a comprehensive set of troubleshooting utilities that i collected during my (short) time of hackintoshing. So it would not be the end if it does not boot but, if you forgive the lousy pun, it would be a pain in the OS. :)

 

I'll give it a try ASAP, eeep! Thank you very much for the advice and the upload. :)

  • Like 1

Eeep, thank you very much! :)

 

The sleep issues are still unresolved, but the older APCI kext solved my shutdown/restart issues, and appears to have shortened the boot time. Now, back to the sleep fixes!

 

Thank you once more!

  • Like 1

Glad to hear it did some good one way or another!

 

Take a look and see if anything might be preventing sleep, in terminal type

pmset -g assertions

also right after attempting to sleep, check the console log. Keep in mind, as long as NullCPUPowerManagement.kext is installed, sleep will never work, so you'll still need to be able to boot without it first. Don't know atom's very well, but maybe SSDT tables in /Extra could help

Hi, eeep!

 

 

PreventUserIdleDisplaySleep 0

PreventSystemSleep 0

PreventUserIdleSystemSleep 0

ExternalMedia 0

UserIsActive 0

ApplePushServiceTask 0

BackgroundTask 0

 

So i think it's not the problem, right? I'll check the console right now to find some clue. Any advice about which logs should i check?

 

Thank you!

just the general messages one that list's everything. Also here is same terminal output on real macbook

macbook ~> pmset -g assertions
9/24/12 10:13:30 AM PDT 
Assertion status system-wide:
  PreventUserIdleDisplaySleep			 0
  CPUBoundAssertion					   0
  DisableInflow						   0
  ChargeInhibit						   0
  PreventSystemSleep					  0
  PreventUserIdleSystemSleep			  0
  ExternalMedia						   0
  DisableLowPowerBatteryWarnings		  0
  EnableIdleSleep						 1
  NoRealPowerSources_debug			    0
  UserIsActive						    0
  ApplePushServiceTask				    0
Kernel Assertions: 0x0004
* Kernel Assertion ID = 500
  Created At = 12/31/69 4:05:34 PM PST 
  Modified At = 12/31/69 4:00:00 PM PST 
  Owner ID = 0x0000000005c1e000
  Level = 0
  Assertions Set = None (4)
* Kernel Assertion ID = 501
  Created At = 12/31/69 4:07:35 PM PST 
  Modified At = 9/22/12 2:42:35 PM PDT  
  Owner ID = 0x0000000005c47000
  Level = 0
  Assertions Set = None (4)
* Kernel Assertion ID = 502
  Created At = 12/31/69 4:07:43 PM PST 
  Modified At = 12/31/69 4:14:05 PM PST 
  Owner ID = 0x0000000005c70000
  Level = 255
  Assertions Set = None (4)
* Kernel Assertion ID = 503
  Created At = 12/31/69 4:07:46 PM PST 
  Modified At = 12/31/69 4:00:00 PM PST 
  Owner ID = 0x0000000005a63000
  Level = 0
  Assertions Set = None (4)
* Kernel Assertion ID = 504
  Created At = 12/31/69 4:07:51 PM PST 
  Modified At = 12/31/69 4:00:00 PM PST 
  Owner ID = 0x0000000005c49000
  Level = 0
  Assertions Set = None (4)

Hi, eeep!

 

In fact, i didn't posted here the second part of the output; i thought it was not important. Silly me. :) Anyway, it's identical to the one you posted but the owner IDs. Opened the Console.app and put my computer to sleep twice, both 2:22 PM and 2:25 PM. Posting the results of both naps (using the power button and selecting the option sleep):

 

 

The first one:

 

9/24/12 2:22:01.551 PM WindowServer[104]: Created shield window 0x55 for display 0x5b81c5c0

9/24/12 2:22:01.552 PM WindowServer[104]: device_generate_desktop_screenshot: authw 0x0(0), shield 0x0(0)

9/24/12 2:22:01.587 PM WindowServer[104]: device_generate_lock_screen_screenshot: authw 0x0(0), shield 0x0(0)

9/24/12 2:22:07.295 PM com.apple.launchd[1]: System: Bug: 12C54: launchd + 80370 [7DCC9489-2DF5-3807-83FA-EF5666EE8078]: 0x0

9/24/12 2:22:07.295 PM com.apple.launchd[1]: System: This API can only be used by a process running within an Aqua session.

9/24/12 2:22:07.299 PM open[1077]: spawn_via_launchd() failed, errno=5 label=[0x0-0x2f02f].aidaemon path=/tbupddmx/aidaemon.app/Contents/MacOS/aidaemon flags=0

9/24/12 2:22:07.302 PM open[1077]: spawn_via_launchd() failed, errno=5 label=[0x0-0x2f02f].aidaemon path=/tbupddmx/aidaemon.app/Contents/MacOS/aidaemon flags=0

9/24/12 2:22:11.848 PM WindowServer[104]: handle_will_sleep_auth_and_shield_windows: no lock state data

9/24/12 2:22:11.947 PM com.apple.launchd.peruser.502[137]: ([0x0-0x30030].backupd-helper[1090]) Could not setup Mach task special port 8: (os/kern) invalid argument

9/24/12 2:22:12.000 PM kernel[0]: AirPort: Link Down on en1. Reason 8 (Disassociated because station leaving).

9/24/12 2:22:13.000 PM kernel[0]: ATHR: unknown locale: 60

9/24/12 2:22:13.871 PM configd[18]: network changed: v4(en1-) DNS- Proxy- SMB

9/24/12 2:22:13.939 PM com.apple.launchd.peruser.502[137]: (com.apple.FontWorker[1098]) Could not setup Mach task special port 8: (os/kern) invalid argument

9/24/12 2:22:14.253 PM com.apple.launchd.peruser.502[137]: (com.apple.mdworker.bundles[1100]) Could not setup Mach task special port 8: (os/kern) invalid argument

9/24/12 2:22:15.000 PM kernel[0]: AirPort: Link Up on en1

 

 

The second one:

 

9/24/12 2:25:01.309 PM WindowServer[104]: Created shield window 0x68 for display 0x5b81c5c0

9/24/12 2:25:01.310 PM WindowServer[104]: device_generate_desktop_screenshot: authw 0x0(0), shield 0x0(0)

9/24/12 2:25:01.349 PM WindowServer[104]: device_generate_lock_screen_screenshot: authw 0x0(0), shield 0x0(0)

9/24/12 2:25:01.421 PM com.apple.launchd.peruser.0[1578]: (0x7feee0506990.anonymous.cron[1577]) Could not setup Mach task special port 8: (os/kern) invalid argument

9/24/12 2:25:02.603 PM sandboxd[1572]: ([1550]) mdworker(1550) deny mach-lookup com.apple.ls.boxd

9/24/12 2:25:02.805 PM sandboxd[1572]: ([1549]) mdworker(1549) deny mach-lookup com.apple.ls.boxd

9/24/12 2:25:03.716 PM sandboxd[1572]: ([1551]) mdworker(1551) deny mach-lookup com.apple.ls.boxd

9/24/12 2:25:08.464 PM com.apple.launchd[1]: System: Bug: 12C54: launchd + 80370 [7DCC9489-2DF5-3807-83FA-EF5666EE8078]: 0x0

9/24/12 2:25:08.464 PM com.apple.launchd[1]: System: This API can only be used by a process running within an Aqua session.

9/24/12 2:25:08.486 PM open[1600]: spawn_via_launchd() failed, errno=5 label=[0x0-0x3e03e].aidaemon path=/tbupddmx/aidaemon.app/Contents/MacOS/aidaemon flags=0

9/24/12 2:25:08.489 PM open[1600]: spawn_via_launchd() failed, errno=5 label=[0x0-0x3e03e].aidaemon path=/tbupddmx/aidaemon.app/Contents/MacOS/aidaemon flags=0

9/24/12 2:25:12.690 PM WindowServer[104]: handle_will_sleep_auth_and_shield_windows: no lock state data

 

 

 

Thanks a lot!

Thanks to post by fantomas1 on another topic where he pointed out this site http://www.mymacnetbook.com/compatibility-chart/ .Looks like lots of good info and resources along with ability to know if sleep even possible. Didn't see a listing for your exact model, but check whatever is closest

Thank you, eeep!

 

I'm going to check it out.

 

EDIT: oh, i'd already seen that. Yeah, my netbook isn't listed: it was paradoxically what encouraged me at the first place. Because it was written nowhere if it would work, but also if it wouldn't.

 

I think i should update that list including my own netbook, and write a guide for it, since i have the latest and greatest Mountain Lion running quite smoothly except for QE/CI (GMA3150) and that sleep issues, and it would be in no way ashamed in comparison to the results of the other hacked netbooks listed, adding to it the fact that i could replicate the process of installation (in fact, i did it a couple of times) any time.

 

But it will have to wait a little bit, because i didn't give up yet: i'll put this mountain kitty to sleep when i want it to, sooner or later.

 

What i'm going to do from now, in chronological order (and your advice or ideas would be much appreciated):

 

1) remove the NullCPU and AppleIntelCPUPower management kexts and throw VoodooPowerMini back in (SleepEnablerUniversal is there already);

 

2) remove the sleep enabler, letting only Voodoo;

 

3) remove voodoo, letting only the sleep enabler;

 

4) remove all legacy power-related legacy kexts;

 

5) Put back AppleIntelCPUPowerManagement and try using the ICH7 dsdt fix again.

 

I'll update the results at this very post, to not to flood the topic.

 

By the way, did you take a look at my console output? Did it show something that i should consider? There's a bug there, i think it's related to touch drivers for MozArt resistive. But before i installed these drivers back in Lion, my netbook didn't sleep either.

 

Thank you very much for the help you've been offering!

  • 1 month later...

Hey!

 

Thanks to fau7i, of osx86.net, who pointed me to the hibernatemode=0 fix, now my netbook sleeps! Could be just perfect... if it wasn't too lazy to wake up. The solution i successfully used for my AMD machine, darkwake=0, simply does not work, as well as darkwake=No or darkwake=10.

 

I'm almost there! Any help will be much appreciated. Thank you all!

×
×
  • Create New...