MBA fails to wake (Platform Failure) after entering Low Power Sleep state

Same here. Seems to be connected to FileFault full disk encryption in some way,

also i did not try without encryption.

Note that the pmset(1) utility has new options, some of which are a bit confusing for me:

- standby

- standbydelay

- destroyfvkeyonstandby

with "standby" set to 1 hibernation should start after sleeping "standbydelay" seconds.

how does standby relate to "hibernationmodes" ? I assume it makes only sense in combination with

hibernationmode set to 3.

"destroyfvkeyonstandby" should control handling of fv keys after wakup. I guess with this set to 1,

you will always have to enter a password after wake, even if "ask for password after sleep" is disabled

somewhere in the security preferences (and the credentials won't be anywhere in ram or on disk).

This is not a fix, but maybe there is a workaround playing with these values. Maybe setting both sleep (automatic sleep timer) and standbydelay to a low value would be an idea, as the power outage immediate hibernation would be unlikely to happen.

axel

Interesting. I am usually having pseudo ttys with multiple terminal windows open, yes.

Never seen any kernel panic though.

Have the same issue with MBA 11" 2011 - 100% reporoducible. It matters not if you have apps open or not. To provoke the bug, simply leave your MBA sleeping until battery is drained. No more wake up after charging - hard reset required. The condition has not changed after the latest firmware patch (as of 19 Sept 11).

same problem, 2011 11" encrypted drive. Terminal is often running but only a single session. always have to do a hard restart when i let the battery drain.

Pardon the thread necromancy, but I have exactly the same problem, 100% reproducable.

I also generally have multiple terminal sessions open, but have tested with all applications closed. I tested again now just to be sure. (Wasn't sure if I tested with terminal closed. Term is like finder to me, it's always running.)

I rarely run screen, but always have multiple ssh sessions with different -D values into different networks open.

Have any of you been able to make any headway?

Do you have any further info on that kernel panic? I'm not finding anything, but may be using the wrong search terms.

I also have whole disk encryption turned on and experience the same issue (waking from sleep after draining the battery then plugging in yields a black backlit screen). This occurs every time, regardless of whether I have any terminal.app running or not.

I've lost work a couple times due to this, but I have sensitive data on my computer and really can't turn off whole disk encryption, so I really hope Apple fixes this soon.

I re-affirm the findings of mike.lwrnc, axelbauer, billimek and my own, but I have bumped into a work-around. Before attempting to start the MBA, leave the charger active for 10-15 minutes. Subsequently you can boot with the power button, this works as expected. However, I still regard this bahaviour as a bug as there is no indication of the condition nor are there instructions as to managing this situation. Apple, FIX IT!

I have the exact same issue 100% reproducible BUT I also know how to exercise the bug without needing to run down the battery. Simply do sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25 then remove the power cord, close the clamshell, plug the power cord back in so it charges for a second, then open the clamshell. You will be in the same blank screen state as if you had let the battery run out.

hibernatemode 25 basically just tells the computer to go into hibernate mode instead of sleep mode wheenver you close the laptop.

destroyfvkeyonstandby tells the computer to power down the ram as soon as it enter hibernate mode.

This problem is way worse than any of you suspect. In all probability the system was intentionally broken in order to provide a backdoor into FV2. Let me explain:

It's impossible to achieve a secure FV2 system without using the following settings:

sudo pmset -a destroyfvkeyonstandby 1 hibernatemode 25

because otherwise what will happen is your FV key will be stored in RAM during both sleep and hibernate states. That means if a bad guy steals your laptop while it's in sleep or hibernate state he's then free to take an unlimited amount of time to attack it. He will be able to retrieve the key from ram as DEMONSTRATED LIVE a few months ago at a security confrence. The tools to preform the attack to retreive the key along with a detailed writeup are availble here:

http://www.frameloss.org/2011/09/18/firewire-attacks-against-mac-os-lion-filevau lt-2-encryption/

So at the risk of repeating myself... the conclusion is it's impossible to have a secure FV2 MBA system because of this bug. I suspect it's a conspiracy because it's too convenient of a bug..

apple has the fV2 system insecure by default (key stored in ram by default) and then apple happens to have a bug that prevents you from flushing that key then hibernating which would be the secure way to do it. Too much of a coincidence.

triumph1337 said: ..Too much of a coincidence.

this might explain Apple silence on the issue!

vonkas wrote:

triumph1337 said: ..Too much of a coincidence.

this might explain Apple silence on the issue!

Well, it wouldn't explain why Apple doesn't make the machine able to wake from sleep.

I had that twice but I found a way to put it on again; hold the power button for 2 seconds or until you see the cursor. This works for me

I don't know why it does that but it must be the same with every 2011 MBA. Apple needs to find a way to fix this.

And the PRAM resets or smc resets will only work if the computer is actually OFF, not on sleep

SOLVED???

I can't believe it. I think I have a solution!

Short version: try creating a new user.

Long version: This problem has been so annoying the last few weeks that I put some more time into it. It happens to me serveral times a day, I'm a consultant so I'll be working on customer systems and switching to my own laptop regularly. I had returned standbydelay at 4200 at some point, so one possible solution was raising that.

First, however, I wanted to see if some program like openvpn, f.lux, caffeine etc. that I have set up start at login was the culprit, thinking maybe something was preventing OSX from getting all the way fully asleep.

I created a new user to test with, as that user would have no startupitems. Hibernation worked immediately. After confirming that user was truly working after cold boots etc., I tried it with my normal user. Suddenly, it's working properly with my normal user as well. I had never previously seen FileVault's password input screen other than at boot. For any others who are not aware, apparently FileVault will re-request the password after hibernation. After that, you will need to re-enter your password for the OSX screen lock assuming you have it enabled. (Previously, I had just assumed those two would be integrated, I'm kind of glad to see they're not.)

My guess is that having enabled FileVault 2 a week after buying and installing the computer, some part of the user data was not properly written to instruct FileVault how to decrypt and enable reading the disk with DestroyFVKeyOnStandby set to 1.

Creating a new user seems to have reinitialized whatever information the bootstrap process was missing and made it possible to resume from hibernation.

Would be curious whether this helps any of the others in this thread.