Jump to content
VirusX

Wake reason: RTC (Alarm) - how to deactivate?

215 posts in this topic

Recommended Posts

Is it just me or did they go and remove com.apple.mDNSResponder.plist from the latest Beta today?

Looks like it has been removed.  That sucks.  Now I have to deal with my computer waking up every 2 hours and now I can't see my other networked computers.

Share this post


Link to post
Share on other sites
Advertisement

yup, I have to confirm: I had to load the discoveryhd.plist again to get internet back to work in DP8 :/

Fun fact: with Chrome I was able to surf the internet even when it was deactivated but no other app (spotify etc) was able to get internet connection.

 

I will test later if my computer wakes every 2 hours now.

 

edit: yes, computer wakes up every two hours again with DP8 :/

I just had tons of DNS errors in my system log - after a few restarts I just won back my internet by booting with discoveryhd unloaded and then load it after boot oO 

Share this post


Link to post
Share on other sites

My computer wakes every 2 hours now with beta 3.

Sep 17 03:23:33 mac kernel[0]: Wake reason: RTC0 (Alarm)
Sep 17 05:12:29 mac kernel[0]: Wake reason: RTC0 (Alarm)
Sep 17 07:01:25 mac kernel[0]: Wake reason: RTC0 (Alarm)
Sep 17 08:50:21 mac kernel[0]: Wake reason: RTC0 (Alarm)

A few minutes ago I decided to take mDNSResponder and mDNSResponderHelper from my mavericks install and disable discoveryd again.  So far it seems to be working well. Keep in mind I still have -DisableSleepProxyClient in the mDNSResponder.plist.

 

I copied /usr/sbin/mDNSResponder* from mavericks to /usr/sbin in yosemite.  I then copied com.apple.mDNSResponder*.plist from mavericks /System/Library/LaunchDaemons to /Library/LaunchDaemons on yosemite (I don't like modifying things in /System if I don't have to).  Make sure to copy all files using sudo.

sudo cp /Volumes/Mavericks/usr/sbin/mDNSResponder* /usr/sbin/
sudo cp /Volumes/Mavericks/System/Library/LaunchDaemons/com.apple.mDNSResponder*.plist /Library/LaunchDaemons/

Then I did:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
sudo launchctl load -w /Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /Library/LaunchDaemons/com.apple.mDNSResponderHelper.plist

Reboot after doing that.

Share this post


Link to post
Share on other sites

I tried to do that too. In order to  add -DisableSleepProxyClient I copied the responder.plist to the desktop, added the link and copied it back. I had to authenticate it my password. The problem is, that now the "path had bad ownership/permissions". So tried to fix the permissions with chmod/chown but I'm not successful :(

I just don't know all those little unix tricks :/

Could you please help me out here? 

 

Also, doing all your steps (excluding -DisableSleepProxyClient edit) resulted in DNS errors after restart. Even more restarts didn't help. Only restarting discoveryhd helped. It's just not my day today :/

Share this post


Link to post
Share on other sites

My computer wakes every 2 hours now with beta 3.

Sep 17 03:23:33 mac kernel[0]: Wake reason: RTC0 (Alarm)
Sep 17 05:12:29 mac kernel[0]: Wake reason: RTC0 (Alarm)
Sep 17 07:01:25 mac kernel[0]: Wake reason: RTC0 (Alarm)
Sep 17 08:50:21 mac kernel[0]: Wake reason: RTC0 (Alarm)

A few minutes ago I decided to take mDNSResponder and mDNSResponderHelper from my mavericks install and disable discoveryd again.  So far it seems to be working well. Keep in mind I still have -DisableSleepProxyClient in the mDNSResponder.plist.

 

I copied /usr/sbin/mDNSResponder* from mavericks to /usr/sbin in yosemite.  I then copied com.apple.mDNSResponder*.plist from mavericks /System/Library/LaunchDaemons to /Library/LaunchDaemons on yosemite (I don't like modifying things in /System if I don't have to).  Make sure to copy all files using sudo.

sudo cp /Volumes/Mavericks/usr/sbin/mDNSResponder* /usr/sbin/
sudo cp /Volumes/Mavericks/System/Library/LaunchDaemons/com.apple.mDNSResponder*.plist /Library/LaunchDaemons/

Then I did:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
sudo launchctl load -w /Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /Library/LaunchDaemons/com.apple.mDNSResponderHelper.plist

Reboot after doing that.

 

I don't have a Mavs install.  Any way you can share that file?  I also had to revert this fix and now get wake ups every 2 hours again.  Would love to fix it as it is constantly ejecting my external HDD's (and slowly driving me insane).  

Share this post


Link to post
Share on other sites

I don't have a Mavs install.  Any way you can share that file?  I also had to revert this fix and now get wake ups every 2 hours again.  Would love to fix it as it is constantly ejecting my external HDD's (and slowly driving me insane).  

Here is a zip of the 2 binaries and the plists.  Binaries go in /usr/sbin and plists in /Library/LaunchDaemons

 

You'll need to manually set owner/group on the files once you copy them

sudo chown root:wheel /usr/sbin/mDNSResponder*
sudo chown root:staff /Library/LaunchDaemons/com.apple.mDNSResponder*.plist

EDIT: Forgot to mention that -DisableSleepProxyClient is already in the plist.

mDNSResponder.zip

Share this post


Link to post
Share on other sites

thanks for the commands mcdougal33. You do have a little typo (chwon instead of chown). I tried to give root:wheel to the launch daemons before - that's why it didn't work :/

 

but my main problem is now as follows:

9/18/14 12:21:35.901 PM mDNSResponder[491]: mDNSResponder mDNSResponder-522.92.1 (Jun  3 2014 12:57:56) starting OSXVers 14
9/18/14 12:21:35.901 PM com.apple.xpc.launchd[1]: (com.apple.xpc.launchd.domain.system) Service "com.apple.mDNSResponder" tried to hijack endpoint "com.apple.mDNSResponder.dnsproxy" from owner: com.apple.networking.mDNSResponder
9/18/14 12:21:35.901 PM mDNSResponder[491]: init_dnsproxy_service: XPCError: Connection invalid
9/18/14 12:21:35.903 PM com.apple.xpc.launchd[1]: (com.apple.xpc.launchd.domain.system) Service "com.apple.mDNSResponder" tried to hijack endpoint "com.apple.mDNSResponder" from owner: com.apple.networking.mDNSResponder
9/18/14 12:21:35.903 PM mDNSResponder[491]: RegisterMachService: 1100 44C unknown error code
9/18/14 12:21:35.903 PM mDNSResponder[491]: ! MACH PORT IS NULL ! bootstrap_checkin failed to give a mach port
9/18/14 12:21:35.904 PM com.apple.xpc.launchd[1]: (com.apple.mDNSResponder) Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
9/18/14 12:21:43.020 PM apsd[53]: dnssd_clientstub set_waitlimit:_daemon timed out (60 secs) without any response: Socket 7
9/18/14 12:22:04.664 PM coreaudiod[270]: dnssd_clientstub ConnectToServer: connect()-> No of tries: 1
9/18/14 12:22:04.663 PM storeaccountd[360]: dnssd_clientstub ConnectToServer: connect()-> No of tries: 3
9/18/14 12:22:04.664 PM coreaudiod[270]: dnssd_clientstub ConnectToServer: connect()-> No of tries: 1
9/18/14 12:22:04.664 PM CalendarAgent[308]: [com.apple.calendar.store.log.caldav.queue] [Adding [<CalDAVAccountRefreshQueueableOperation: 0x7fc5cb87be50; Sequence: 0>] to failed operations.]
9/18/14 12:22:05.439 PM Google Chrome[262]: dnssd_clientstub set_waitlimit:_daemon timed out (60 secs) without any response: Socket 19

Even a few restarts didn't help. I only get internet back when I load the discoveryhd back :/

I also just tried your files - same problem. I don't know what's missing. It has worked before...

 

maybe it has something to do with that:

9/18/14 12:22:07.758 PM coreaudiod[270]: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mDNSResponder Socket:5 Err:-1 Errno:61 Connection refused
9/18/14 12:22:07.759 PM coreaudiod[270]: dnssd_clientstub ConnectToServer: connect() failed path:/var/run/mDNSResponder Socket:6 Err:-1 Errno:61 Connection refused

Share this post


Link to post
Share on other sites

Try unloading all related plists then load them again with launchctl.  Also, post the output of 'ls -l /Library/LaunchDaemons/com.apple.mDNS*.plist'

 

 

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist
sudo launchctl unload -w /Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl unload -w /Library/LaunchDaemons/com.apple.mDNSResponderHelper.plist
sudo launchctl load -w /Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /Library/LaunchDaemons/com.apple.mDNSResponderHelper.plist

Share this post


Link to post
Share on other sites

Hi , i've resolved this issue editing com.apple.discoveryd.plist and com.apple.mDNSResponder.plist, just moving this parameter from one to other :

 

<key>Disabled</key>
    <false/>

 

and adding mDNSResponder binaries into /usr/sbin/

 

repairing rights, that's all, and thank you guys !

post-15471-0-82729600-1411883884_thumb.jpg

Share this post


Link to post
Share on other sites

Adding Disabled=YES to discoveryd will work.  Repair permissions and reboot.

 

You could also run 'sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.discoveryd.plist' to disable discoveryd.

Share this post


Link to post
Share on other sites

nexus77777, do you still have to use the com.apple.mDNSResponder.plist as well?

 

Do you mean the "disabled" com.apple.discoveryd.plist ? Yes, it still in "LaunchDeamons" folder

Share this post


Link to post
Share on other sites

Same issues on a real MacPro 3,1 here running beta 4 - haven't tried on the hackintosh yet. Applying the fix described above kills internet for me too.

 

I've been experiencing very poor network connectivity (wifi) under this beta regardless though. It won't load pages for ~10min after boot and then at random intervals afterwards, it's like a tap, on or off. Definitally related to the OS, northing to do with signal strength or local internet, am using hackintosh favourite TP-Link WDN-4800 which works great in real Mac's too.

 

Hope they sort all of this out before final GM...

Share this post


Link to post
Share on other sites

Can I please ask what is the exact method people are using for the most recent Yosemite releases to disable the 2 hour wake?

 

Does it require the addition of files from an older build or just en edit of the current file?

Share this post


Link to post
Share on other sites

I'm currently too busy to test things. I plan to wait for the final version of yosemite and then make a fresh install and go from there.

Currently, after all the fixes I tried, I don't get internet connection after boot so I have to unload and then load the discoveryhd.plist again to get it back to work. Without the discoveryhd.plist I only get DNS errors and no internet connection.

Share this post


Link to post
Share on other sites

All I'm doing is dropping the files from the post a couple pages back in their respective locations and repairing permissions and Internet works immediately, I don't even have to reboot. After each update I have to do this because the Internet breaks every time. Other than that, it seems to be working fine.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By holyfield
      There are plenty of users who suggest to use darkwake=8 or darkwake=10 or darkwake=0 boot args to solve sleep issues.
       
      Are these suggestions valid at all?
       
      For first we have to clarify something about Darkwake. The DarkWake feature was for first introduced in Mac OS X Lion. This feature allows to wake up certain parts of computer from sleep, while leaving other parts in sleep mode (for example display etc). Darkwake = display stays dark when comp wakes and performs some tasks. When tasks are done, comp should go back to sleep. But on Hack's Darkwake caused several problems, for example comps went into state, where those become inaccessible and forced reboot were needed. On some cases Darkwake caused reboots too and.. Darwake is related to Power Nap which is available since OS X Mountain Lion.
       
      Disclaimer! Before posting below please read it:
       
      If you really want to get some help from Hackintosh community, learn how to leave others out of guesswork! Learn how to collect diagnostics data which can help others on solving your case. It's annoying to ask over and over to provide some diagnostics related to Hack issue. That's why there are millions on unanswered posts on Hackintosh forums, their authors doesn't respect other's actually, they do not think out of their own shoes. Your first question before posting should be, what data is needed to help me, do I have provided all data available to help me immediately?
       
       
      Darkwake and XNU
       
      Darkwake is part of XNU. 
       
       
      Darkwake behaviours are defined in IOPMrootDomain.cpp.
       
      The easiest way to check XNU version is to use terminal command uname -av. 
       
      uname -av Darwin MyHack.local 19.2.0 Darwin Kernel Version 19.2.0: Sat Nov 9 03:47:04 PST 2019; root:xnu-6153.61.1~20/RELEASE_X86_64 x86_64 According to this macOS Catalina 10.15.2 uses XNU 6153.61.1.
       
      The latest publicly available source code of XNU is 4903.241.1. So we cannot check source code of latest XNU's. Please correct me if I'm wrong. 
       
      Code below reveals that boot arg darkwake correlates to enum gDarkWakeFlags.
      PE_parse_boot_argn("darkwake", &gDarkWakeFlags, sizeof(gDarkWakeFlags));  
      So lets check the xnu-4903.241.1/iokit/Kernel/IOPMrootDomain.cpp for Darkwake flags:
      // gDarkWakeFlags enum { kDarkWakeFlagHIDTickleEarly = 0x01, // hid tickle before gfx suppression kDarkWakeFlagHIDTickleLate = 0x02, // hid tickle after gfx suppression kDarkWakeFlagHIDTickleNone = 0x03, // hid tickle is not posted kDarkWakeFlagHIDTickleMask = 0x03, kDarkWakeFlagAlarmIsDark = 0x0100, kDarkWakeFlagGraphicsPowerState1 = 0x0200, kDarkWakeFlagAudioNotSuppressed = 0x0400 }; Let's translate these values into decimals and easier to read strings
      HID Tickle Early = 1 HID Tickle Late = 2 HID Tickle None = 3 HID Tickle Mask = 3 Alarm Is Dark = 256 Graphics Power State 1 = 512 Audio Not Suppressed = 1024 HID = Human-interface devices, such as keyboards, pointing devices, and digitizers like pens and touch pads.
       
      As flags are used for bitwise operations, then we can easily notice that combinations 10 and 8 are for sure invalid now. darkwake=8 equals actually to darkwake=0 and darkwake=10 equals to darkwake=2.
       
      If we check older XNU versions, then these values are removed since XNU 2782.1.97 ( = Yosemite ):
      kDarkWakeFlagIgnoreDiskIOInDark = 0x04, // ignore disk idle in DW kDarkWakeFlagIgnoreDiskIOAlways = 0x08, // always ignore disk idle kDarkWakeFlagIgnoreDiskIOMask = 0x0C According to this boot flags darkwake=8 and darkwake=10 are obsolete if you have Yosemite or newer macOS as related flags are removed from XNU. 
       
      What is the default value for darkware boot arg?
       
      According to XNU source code the default value of boot arg darkware is 3 (darkwake=3):
      static uint32_t gDarkWakeFlags = kDarkWakeFlagHIDTickleNone; We have to clarify that xnu 4903.221.2 is used since macOS Mojave 10.14.1 and xnu 4903.241.1 is used since macOS Mojave 10.14.3. How about the latest macOS? Sadly there is no source code available. 
       
      To figure out which value is defined on latest kernel we have to download the latest available Kernel Debug Kit, which is 10.15.1 build 19B77a. By using Hopper Disassembler we see that default value on macOS Catalina 10.15.1 for gDarkWakeFlags is 0x00000003, which equals to 3.
      __ZL14gDarkWakeFlags: // gDarkWakeFlags ffffff80012b93b0 dd 0x00000003 So by default Darkwake should not post any HID Tickle's. This also reveals the secret why some users encounter issues with frozen peripheral device's on Hack's when Power Nap is enabled. To use Darkwake on Hack's require very well configured USB ports.
       
       
      Power Nap & Darkwake
       
      If you have Power Nap disabled then computer shouldn't wake automatically. On most cases darkwake boot arg affects how computers should behave on case of Power Nap enabled. If everything is configured properly you do not need define darkwake boot flag at all. Anyhow, there might be motherboards, which benefit from user defined value. But keep in mind that darkwake=8 and darkwake=10 are obsolete since Yosemite.
       
       
      Which values are valid for darkwake?
       
      As flags are used for bitwise operations, then these values are valid:
       
      darkwake=0
      darkwake=1 (darkWakePostTickle behaviour)
      darkwake=2 (darkWakePostTickle behaviour)
      darkwake=3 (darkWakePostTickle behaviour)
      darkwake=256
      darkwake=257
      darkwake=258
      darkwake=259
      .. and so on...
       
      As I'm not familiar how PE_parse_boot_argn function exactly works, I cannot say much about boot arg darkwake=0. According to source code there is no any checks or behaviours defined for darkwake=0. There is a huge chance that using darkwake=0 actually equals to darkwake=3. I hope someone can clarify from source code what exactly happens if darkwake=0 is used trough PE_parse_boot_argn, but it's obvious that darkwake=0 does not equal to darkwake=NO (or darkwake=FALSE). darkwake=0 does not disable power nap, it only affects HID tickle. Please note that darkwake=3 is combination of flags 1 & 2. 1 + 2 = 3. On case we say to the system to do early (1) and later (2) HID tickle both (3), there is no any tickle at all.
       
      Some code samples from IOPMrootDomain:
      else if (!darkWakeMaintenance) { // Early/late tickle for non-maintenance wake. if (((gDarkWakeFlags & kDarkWakeFlagHIDTickleMask) == kDarkWakeFlagHIDTickleEarly) || ((gDarkWakeFlags & kDarkWakeFlagHIDTickleMask) == kDarkWakeFlagHIDTickleLate)) { darkWakePostTickle = true; } } if (darkWakePostTickle && (kSystemTransitionWake == _systemTransitionType) && (gDarkWakeFlags & kDarkWakeFlagHIDTickleMask) == kDarkWakeFlagHIDTickleLate) { darkWakePostTickle = false; reportUserInput(); } if (powerState > maxPowerState) { DLOG("> plimit %s %p (%u->%u, 0x%x)\n", service->getName(), OBFUSCATE(service), powerState, maxPowerState, changeFlags); *inOutPowerState = maxPowerState; if (darkWakePostTickle && (actions->parameter & kPMActionsFlagIsDisplayWrangler) && (changeFlags & kIOPMDomainWillChange) && ((gDarkWakeFlags & kDarkWakeFlagHIDTickleMask) == kDarkWakeFlagHIDTickleEarly)) { darkWakePostTickle = false; reportUserInput(); } } void IOPMrootDomain::reportUserInput( void ) { #if !NO_KERNEL_HID OSIterator * iter; OSDictionary * matching; if(!wrangler) { matching = serviceMatching("IODisplayWrangler"); iter = getMatchingServices(matching); if (matching) matching->release(); if(iter) { wrangler = OSDynamicCast(IOService, iter->getNextObject()); iter->release(); } } if(wrangler) wrangler->activityTickle(0,0); #endif } As you see from code examples above, there is no any huge mystery about darkwake boot arg and you should use it mostly on case when you really need to manipulate HID tickle behaviour. On most cases it's more important to properly configure you system power management rather than paying with darkwake boot arg, which can be done via terminal command pmset.
       
       
      Power Management
       
      To check Power Management settings use terminal command:
      pmset -g Also you can use Hackintool to check power management settings:
       

       
      Power Management Settings explained:
       
      displaysleep - display sleep timer; replaces ’dim’ argument in 10.4 (value in minutes, or 0 to disable) disksleep - disk spindown timer; replaces ’spindown’ argument in 10.4 (value in minutes, or 0 to disable) sleep - system sleep timer (value in minutes, or 0 to disable) womp - wake on ethernet magic packet (value = 0/1). Same as "Wake for network access" in the Energy Saver preferences. ring - wake on modem ring (value = 0/1) powernap - enable/disable Power Nap on supported machines (value = 0/1) proximitywake - On supported systems, this option controls system wake from sleep based on proximity of devices using same iCloud id. (value = 0/1) autorestart - automatic restart on power loss (value = 0/1) lidwake - wake the machine when the laptop lid (or clamshell) is opened (value = 0/1) acwake - wake the machine when power source (AC/battery) is changed (value = 0/1) lessbright - slightly turn down display brightness when switching to this power source (value = 0/1) halfdim - display sleep will use an intermediate half-brightness state between full brightness and fully off (value = 0/1) sms - use Sudden Motion Sensor to park disk heads on sudden changes in G force (value = 0/1) hibernatemode - change hibernation mode. Please use caution. (value = integer) hibernatefile - change hibernation image file location. Image may only be located on the root volume. Please use caution. (value = path) ttyskeepawake - prevent idle system sleep when any tty (e.g. remote login session) is ’active’. A tty is ’inactive’ only when its idle time exceeds the system sleep timer. (value = 0/1) networkoversleep - this setting affects how OS X networking presents shared network services during system sleep. This setting is not used by all platforms; changing its value is unsupported. destroyfvkeyonstandby - Destroy File Vault Key when going to standby mode. By default File vault keys are retained even when system goes to standby. If the keys are destroyed, user will be prompted to enter the password while coming out of standby mode.(value: 1 - Destroy, 0 - Retain)  
      If you want to disable proximitywake the this command should be used:
      sudo pmset -a proximitywake 0  
      Recommended settings for Hack's are:
      sudo pmset -a hibernatemode 0 sudo pmset -a proximitywake 0 sudo pmset -a powernap 0 Settings above disable Hibernate, Bluetooth wake by iDevices and Power Nap.
       
      To check what might prevent computer from going into sleep we can pmset tool:
      pmset -g assertions  
      So, before using blindly darkwake boot arg to solve some sleep issues, make instead sure that USB ports and Power Management settings of your Hack are configured properly.
       
       
      Sleep & Wake
       
      Quite often Hack's users have sleep/wake issues because they don't pay attention to the fact that Apple's macOS is developed for Apple hardware in mind, not regular PC's. 
       
      Of course sleep mode isn't something that Apple has invented first. Since December 1996 ACPI superseded APM. ACPI - Advanced Configuration and Power Interface. APM - Advanced Power Management. The ACPI specification defines several states for various hardware components and devices. There are global "Gx" states and sleep "Sx" states specified.
       
      Gx Name Sx Description G0 Working S0 The computer is running and the CPU executes instructions. "Awaymode" is a subset of S0, where monitor is off but background tasks are running G1 Sleeping S1 Power on Suspend (POS): Processor caches are flushed, and the CPU(s) stops executing instructions. The power to the CPU(s) and RAM is maintained. Devices that do not indicate they must remain on may be powered off S2 CPU powered off. Dirty cache is flushed to RAM S3 commonly referred to as Standby, Sleep, or Suspend to RAM (STR): RAM remains powered S4 Hibernation or Suspend to Disk: All content of the main memory is saved to non-volatile memory such as a hard drive, and the system is powered down G2 Soft Off S5 G2/S5 is almost the same as G3 Mechanical Off, except that the power supply unit (PSU) still supplies power, at a minimum, to the power button to allow return to S0. A full reboot is required. No previous content is retained. Other components may remain powered so the computer can "wake" on input from the keyboard, clock, modem, LAN, or USB device G3 Mechanical Off   The computer's power has been totally removed via a mechanical switch (as on the rear of a PSU). The power cord can be removed and the system is safe for disassembly (typically, only the real-time clock continues to run using its own small battery)  
      Since Mac OS X Lion Apple is using DarkWake, which were wrapped into Power Nap on OS X Mountain Lion. To understand and fix macOS sleep issues we also need the knowledge about sleep states which macOS comps may have. To check log of macOS computers sleep/wake we can use pmset tool. Following terminal code prints sleep/wake history.
      pmset -g log|grep -e " Sleep " -e " Wake "  
      I to check more closely sleep history then we can recognise that macOS has at least 3 different sleep "modes":
       
      Software sleep Idle sleep Maintenance sleep  
      Software sleep
      Software sleep is trigged by computer user or by some software, which is configured to put comp sleep after certain tasks done.
       
      Idle sleep
      Idle sleep is triggered by idle timer. Each time user interacts with computer idle timer is reset. If users doesn't interact within idle timer countdown time, then Idle sleep is triggered.
       
      Maintenance sleep
      If user has enabled "Wake for Ethernet network access", then macOS goes from Idle or Software sleep into Maintenance sleep immediately. 
       
      Power Nap
      If Power Nap is enabled, then computer wakes up automatically after certain period of time, handles certain tasks and goes back to sleep. Apple's documentation reveals that behaviour of power nap doesn't depend only macOS version running on comp but at hardware and it's firmware too. Documentation clearly states that comps made on different time behave differently. which points directly that Power Nap is related to the hardware/firmware too.
       
       
      According quote above we have to very carefully choose which firmware is emulated on Hack. Changing SMBIOS on Clover/Opencore can help to solve sleep issues or cause them.
       
      An example of sleep log when powernap is enabled:
      2020-01-05 09:03:23 +0200 Sleep Entering Sleep state due to 'Idle Sleep': Using AC (Charge:0%) 21 secs 2020-01-05 09:04:29 +0200 Sleep Entering Sleep state due to 'Maintenance Sleep': Using AC (Charge:0%) 1945 secs 2020-01-05 09:37:39 +0200 Sleep Entering Sleep state due to 'Maintenance Sleep': Using AC (Charge:0%) 3187 secs 2020-01-05 10:31:33 +0200 Sleep Entering Sleep state due to 'Maintenance Sleep': Using AC (Charge:0%) 12467 secs 2020-01-05 14:00:06 +0200 Sleep Entering Sleep state due to 'Maintenance Sleep': Using AC (Charge:0%) 11312 secs 2020-01-05 17:08:40 +0200 Wake DarkWake to FullWake from Normal Sleep [CDNVA] : due to UserActivity Assertion Using AC (Charge:0%)  
      An example of sleep log, when ethernet wake and power nap is disabled:
      2020-01-03 18:15:43 +0200 Sleep Entering Sleep state due to 'Idle Sleep':TCPKeepAlive=inactive Using AC (Charge:0%) 3210 secs 2020-01-03 19:09:13 +0200 Wake Wake from Normal Sleep [CDNVA] : due to XDCI CNVW/HID Activity Using AC (Charge:0%) 207 secs 2020-01-03 19:12:40 +0200 Sleep Entering Sleep state due to 'Idle Sleep':TCPKeepAlive=inactive Using AC (Charge:0%) 165903 secs 2020-01-05 17:17:43 +0200 Wake Wake from Normal Sleep [CDNVA] : due to XDCI CNVW/HID Activity Using AC (Charge:0%) As we see from log above, computer stays in sleep without any wakes and no 'Maintenance Sleep'.
       
      So there are several variables which have effect on your computer sleep/wake behaviour and the solution that helped another people, might be useless or even worse on you case.
       
      ...
    • By holyfield
      Description
       
      Idle Sleep issue detected on both, genuine Mac's and Hack's, where have installed latest macOS Catalina 10.15.2.
       
      Currently known about the issue:
      Issue noticed by various users after upgrading to macOS 10.15.2 Both genuine Mac's and Hack's are affected. Comps which are running on battery power are not affected as agent is disabled at battery power. macOS 10.15.2 replaces previous version of parsec-fbf agent. macOS 10.15.2 kernel uses new version of XNU 6153.61.1. macOS 10.15.1 kernel uses XNU 6153.41.3. Bot the macOS 10.15.2 and macOS 10.15.0 use the same com.apple.parsec-fbf.plist launch agent definition file. Not sure are all comps with 10.15.2 affected or only with specific system configuration Issue is not reported on any older macOS versions this far. Only Idle Sleep is affected, Software Sleep works fine. Agent can be killed via Activity Monitor, but it revives immediately again and still prevents the Idle Sleep Agent does not stop display to go into sleep, which makes hard to notice the issue on genuine Macs. Disabling parsec-fbf agent solves the issue  
      CoreParsec.framework is part of Siri
       
      pares-fbf is part of CoreParsec.framework which is installed on /System/Library/PrivateFrameworks/CoreParsec.framework.
       
      Info from /System/Library/PrivateFrameworks/CoreParsec.framework/Versions/Current/Resources/Info.plist:
      Bundle identifier: com.apple.siri.parsec.CoreParsec Privacy - Location Usage Description: Spotlight, Messages, Lookup & Safari Suggestions use your location to provide more accurate local results.  
       
      Content of com.apple.parsec-fbf.plist which defines the agent:
      <?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>EnablePressuredExit</key> <true/> <key>EnableTransactions</key> <true/> <key>Label</key> <string>com.apple.parsec-fbf</string> <key>LaunchEvents</key> <dict> <key>com.apple.xpc.activity</key> <dict> <key>com.apple.parsec-fbf.flush</key> <dict> <key>AllowBattery</key> <false/> <key>Interval</key> <real>3600</real> <key>Priority</key> <string>Maintenance</string> </dict> </dict> </dict> <key>MachServices</key> <dict> <key>com.apple.parsec-fbf</key> <true/> </dict> <key>POSIXSpawnType</key> <string>Adaptive</string> <key>ProcessType</key> <string>Background</string> <key>Program</key> <string>/System/Library/PrivateFrameworks/CoreParsec.framework/parsec-fbf</string> </dict> </plist>  
      Comparison of parsec-fbf on different Catalina versions:
       
      MD5 (10.15.0/parsec-fbf) = e20c200814c4ce5fcd3ae5af7394e1d1 MD5 (10.15.1/parsec-fbf) = f3fe4e16be71798fd7d3b23be089082e MD5 (10.15.2/parsec-fbf) = a97bb8b8227c063289a6e0d43582b10f  
      parsec-fbf agent binary file's are different in each macOS Catalina version. But seems that the biggest change is made in Catalina macOS 10.15.2.
       
      Binary comparison:
       
      10.15.0/parsec-fbf = 1 742 192 bytes 10.15.1/parsec-fbf = 1 736 640 bytes 10.15.2/parsec-fbf = 1 802 832 bytes  
      Left file: 10.15.0/parsec-fbf Right file: 10.15.1/parsec-fbf 1561745 same byte(s) 58019 left orphan byte(s) 52467 right orphan byte(s) 122428 difference byte(s) Left file: 10.15.1/parsec-fbf Right file: 10.15.2/parsec-fbf 1450705 same byte(s) 129662 left orphan byte(s) 195854 right orphan byte(s) 156273 difference byte(s) Left file: ./10.15.0/parsec-fbf Right file: ./10.15.2/parsec-fbf 1443572 same byte(s) 150586 left orphan byte(s) 211226 right orphan byte(s) 148034 difference byte(s)  
      According to knowledge that issue with parsec-fbf agent is not reported before Catalina 10.15.2 and each Catalina versions has his own versions of parsec-fbc agent, then we can conclude that issue is specific to the Catalina 10.15.2 only, until reported otherwise. So no need to concern if you have macOS 10.15.1 or older. Anyway, if you upgrade to 10.15.2 and get sleep issues, you have to check your system for issue described in this post. On some cases this might look like Buletooth issue but actually it's not, because when yo disable parsec-fbf agent, sleep works immediately again.
       
      How to check?
       
      pmset -g assertions  
      If computer has Idle Sleep issue and com.apple.parsec-fbf.flush is listed in assertions, then this might be the reason of why Idle Sleep fails.
       
      An example:
      pid 321(UserEventAgent): [0x00000145000b82a0] 03:09:42 BackgroundTask named: "com.apple.parsec-fbf.flush"  
      How to check sleep log?
      pmset -g log|grep -e " Sleep " -e " Wake "  
      Reason
       
      It's unknown what exactly causes this issue. Somehow parsec-fbf agent goes into state where it prevents comp to go into Idle Sleep. Probably the latest version of parsec-fbf agent introduced in macOS 10.15.2 has some kind of bug which resets idle timer. As macOS kernel uses new version of XNU (6153.61.1), this might be somehow related to both, parsec-fbf agent and kernel.
       
      Current solution:
       
      Please note that just disabling Siri doesn't help, as parsec-fbf agent is responsible for sending Spotlight, Messages, Lookup & Safari searches data too, not only Siri searches.
      launchctl unload -w /System/Library/LaunchAgents/com.apple.parsec-fbf.plist  
      As this agent sends and flushes analytical data (Spotlight, Messages, Lookup & Safari searches) sent to Apple, no any harm happens to you, if you disable this agent, Apple just cannot spoof after you anymore. 
       
      parsec-fbf agent reads and writes files in users Cache folder: ~/Library/Caches/com.apple.parsecd. If you want flush these, you can do it manually.
       
      Flushing spoofing cache manually:
      cd ~/Library/Caches rm -R com.apple.parsecd  
       
       
    • By eraser0
      Hi Happy new YEAR 
       
      My laptop doesn't sleep at all
       
      sometime it sleeps with darkwake=0,1,2 but leads to shutdown
      other arguments the screen just turns off and it keeps running 
       
      this is my conflig plist if anyone would help me
       
       
      config2.plist
    • By M_Furtwangler
      嗨,大家好
      Hi, everybody
      After successfully installing the Catalina and Opencore bootloaders, I encountered a problem that some applications would crash after waking up,
      Such as Chrome and Tencent QQ, these applications will become unresponsive and only be quited by force, even the system could not power off normally.
      However, none of these problems occurred before sleep.
      In addition, all of these issues occur when SMBIOS is iMac and iGPU is enabled in the BIOS, but not when SMBIOS is iMac Pro or iGPU is disabled in the BIOS.
      I am thinking that the problem may be iGPU related and I cannot fix it.
      please help me.
       
      I have attached my EFI and IOReg files
       
      My specifications:
      Asus Z170i Pro gaming
      Intel i5-8600k
      Radeon RX580 8GB
      Radeon RX580 8GB
       
      OC.zip
      iMac.ioreg
×