Sleep Wake Failure with High Sierra 10.13.2

I totally agree ghogho, there's something amiss in the OS. I suspect that because PN is on by default, the only folks uncovering the problem were ones, like me, who don't like my machine doing something while I'm sleeping and I turned it off. My posts were an effort to give Apple's software engineers some idea of a common thread to the problem. You have stated it quite succinctly. Hopefully, they read this thread and it will give them an avenue to follow.

I have rried several fixes none are working my imac is late 2012. Hey apple 🍏 recall and give is new ones before you lose our business. Just a note i leave it in the power consumption sleep state it wakes up but if you leave the email open it ***** them off the servers and you cant ise your ios devive to download your mail.

I have this problem too, and I've tried numerous "fixes" proposed by Apple. What is super frustrating is that this is clearly a known problem, yet no one I spoke to at Apple had any clue about it. If this is a known issue, why is Apple staying silent? At least with the battery issue they proposed a fix. Here, silence.

An update on the situation with 'Power Nap' (PN) settings.

With PN enabled, as I commented earlier, the computer never goes to sleep (remains unclear what exactly 'sleep' means, i.e. standby, hibernate or ...?), as, most likely, there are always processes that keep it busy, especially with an internet connection active. The situation with PN unchecked and no other Energy Saver option selected is not clear as the computer still did not go into 'sleep', strangely enough.

As soon as the 'Put hard disc to sleep when possible' option was selected, it took a few hours only before the 'sleep' went to a unwanted, double chime reboot, from whatever that 'sleep' state was!

An obviously faulty behaviour, so closely related to a setting, is an overwhelming evidence that the malfunction is with system. Since I have used the computer from new, for over four years, with several different OS updates and it worked flawlessly until updating to High Sierra, Apple gives me no choice but to conclude that the High Sierra OS update is the culprit.

Thanks for this. Obviously I would backup everything all over the place anyway before doing it, but would this be a clean install (i.e. total wipe) or would it wipe out just the High Sierra OS and replace it? I can't wait to get back to using Sierra!

Jim

jim.123 wrote:

Thanks for this. Obviously I would backup everything all over the place anyway before doing it, but would this be a clean install (i.e. total wipe) or would it wipe out just the High Sierra OS and replace it? I can't wait to get back to using Sierra!

Jim

Wipe and installing high sierra didn't help at all for me. Reinstalling 10.12.6 is the only fix which has stuck.

Here is my story. It started about a week ago. I found my supposed-to-be-sleeping MacBook Air (HS 12.3.3) awake in the middle of the night, green screen with a folder with a flashing question mark. Hard reboot, everything back to normal. From time to time, I started to have wake-from-sleep issues (ie, open the lid, black screen, nothing happens, hard reboot using the power button).


The flashing question mark folder re-appeared almost every night, or in the morning when opening the laptop lid.


Tried everything I found in internet, including PRAM, SMC, safeboot, recoverymode and diskutility, reisntalled combo 10.13.3, installed the recent 10.13.3 supplemental. Nothing works.


Going through console system.log, I found a weird "5 [RE] Reachability changed" as the last entry before the freeze. See these examples:


Feb 21 00:27:35 DZ-MacBookProi5 uc[67]: 5 [UP] Transitioning from 3 to 1


Feb 21 00:27:38 DZ-MacBookProi5 com.apple.xpc.launchd[1] (com.apple.preference.displays.MirrorDisplays): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.

Feb 21 00:27:41 DZ-MacBookProi5 uc[67]: 5 [RE] Reachability changed

Feb 21 08:27:38 localhost bootlog[0]: BOOT_TIME 1519198058 0

Feb 21 10:55:45 DZ-MacBookProi5 CheckmateIdleDaemon[117]: The system WILL go to sleep...


Feb 21 10:55:45 DZ-MacBookProi5 loginwindow[122]: magsafeStateChanged state changed old 1 new 2

Feb 21 10:55:46 DZ-MacBookProi5 fud[30895]: objc[30895]: Class MobileAssetUpdater is implemented in both /System/Library/PrivateFrameworks/MobileAccessoryUpdater.framework/Support/fud (0x102ec4e10) and /System/Library/AccessoryUpdaterBundles/ApplePowerAccessoryUpdater.bundle/Conte nts/MacOS/ApplePowerAccessoryUpdater (0x102fd28f8). One of the two will be used. Which one is undefined.

Feb 21 10:55:46 DZ-MacBookProi5 uc[64]: 5 [RE] Reachability changed

Feb 21 11:18:41 localhost bootlog[0]: BOOT_TIME 1519208321 0

Isthat "Reachability changed" entry involved with the freeze? this is the last entry in system.log before the freeze. Anybody seeing the same entry?


As last resort, I tried to disable safesleep.

In /private/var/vm i found a sleepimage file, created on February 15 (when I started to have the issue, but it might be a coincidence).


I disabled safesleep (pmset -a hybernatemode 0), rebooted in recovery mode (CMD+R), disabled SIP (csrutil disable), rebooted, deleted the safesleep file, rebooted in recovery mode, enabled SIP (csrutil enable) and re-booted normally.


System has created a new sleepimage file.


In summary, I removed the old sleepimage, I left hibernatemode on 0. Let's see what happens.


Nothing for a few days and then it comes back again. This is only the last one out of several in the past few days:

Report Version: 26

Hardware model: iMac13,1

Time Awake Since Boot: 36000s

Binary Images:

...

The randomness and absence of association with a particular event or activity is maddening.

Yes, I just got the notification that it has been removed. I was being too mean to Apple. I think the guy who reported it has a computer repair business and is trying to drum up customers. I will definitely have to be more polite and keep my caps lock off. At this point I don't care what is causing the error I just want Apple to get it fixed. I am going to leave Power Nap off for a couple of days and see what kind of error reports I get and send some more in. Good luck to us all.

This is very intriguing. How is it possible to know who reported your comment? I thought it is an automated process. Are there known moderators and/or people who act on Apple's side? I think this is a reasonable question, as it can indicate the level of awareness of the Sleep Wake Failure problem discussed here.

I am fully aware that this is Apple's site and they can delete, remove and altogether shut down anything that is not in their interest. However, for as long as it is open and allowed, the absence of acknowledgement and any other response from Apple is very disrespectful to so many Apple customers.

Yes, I don't know who the guy is that was offended and don't care but after I asked him twice if he had a solution he sent me a link to some commercial site that apparently does Apple repairs. Interesting that doing that isn't against some Apple policy.

Anyway my computer just did the self restart less than 24 hours since I installed HS 10.13.3 Supplemental so the Apple engineers haven't done anything to fix the problems that my computer has with HS. I sent the error log in to the engineers or at least to some link that Apple gave me back on Feb. 4 but who knows if they even look at those. I am beginning to lose hope that they are going to fix this problem.

ghogoh wrote:

Whichever the case may be, hundreds of Apple users, at least those showing on this and the thread I mentioned above, quite likely many more, have been affected over an extended period of time and this forum becomes as good as any for them to express their expectations from Apple to help resolve the issue.

It is, however, pointless to do so. If you want to express something to Apple, contact them directly. Use the Contact Support button at the top right of every page. Use the feedback page. Or, make an appointment at the Genius Bar at your local Apple Store. If you contact Apple in any of those ways, they track the issues. That's how they learn the scope of a particular problem.

Mind you, I got involved in this thread and as a result, an Apple worker got in touch with me about the problem.

We have exchanged several emails, had phone calls and I have sent in diagnostic reports as a result, so it does have an impact.

The problem is still unresolved of course, I have several crashes every day and I am now pathetically excited to be downgrading back to Sierra later on today !

jim.123 wrote:

Mind you, I got involved in this thread and as a result, an Apple worker got in touch with me about the problem.

We have exchanged several emails, had phone calls and I have sent in diagnostic reports as a result, so it does have an impact.

The problem is still unresolved of course, I have several crashes every day and I am now pathetically excited to be downgrading back to Sierra later on today !

No, that's not exactly how it worked. Enough people contacted Apple directly that they became aware of an issue. Once they are aware of an issues, they sometimes search the forum for examples and yes, reach out to people. So, you're getting a free ride, so to speak, from the people who actually reported the issue to Apple.

This is the classic voltage droop issue.

let me add some insight into this. Every microprocessor has something called vmin which is the minimum voltage that is needed for certain Fmax. in the case of this issue, the new operating system has the code running in a way that demands higher instance electrical current that the power supply system and decoupling capacitors cannot provide anymore. this causes the Vmin dip below the threshold therefore causes the wakeup fails. Apple could do several things to amend this. One, to rewrite the portion of the operating system to control the electrical current steps caused by the wakeup, aka, power gating, so that it doesn't cause the Vmin issue. Second, Apple could change their power gating code in a way that raising the voltage supply when it enters into sleep mode so that it has higher initial power supply level to prevent the Vmin dip below the threshold.