2012 mbp - slow wake up from sleep after last mbp update

Hi, I have the same issue with my MBP 2012 non-retina. After some time with the lid closed and on AC power, the MBP goes into hybernation. After opening the lid, I have to wait for ~30 s before I can enter my password and start working.

I used the suggestion (in Terminal: sudo pmset -a autopoweroff 0) and hope that Apple fixes this unexpected behavior.

While we all appreciate your "hoping", it would really help a lot if you call AppleCare and open a ticket about it and indicate your issues with this behavior. Thanks in advance.

I fear that your hope will be in vain. As I said in my previous post, this behaviour seems to be intended in order to comply with the very strict EU regulations. So guess there will be no fix. Next time I set up OSX anew I'll make sure to avoid the 2.0 Update.

Well, like I said, I don't have a problem with the time it takes to come out of hibernation. I actually don't have this patch installed but have enabled my Standby mode, which causes the same hibernation state after 4200 seconds of sleeping on battery power. What bothers me is that the Mac has to wake up each and every time I plug/unplug the charger from it. That is unnecessary and defeats the purpose of these additional hibernation states the system enters. That's the problem I have with the system, not the hibernation state... that can be disabled. What I don't get is why the stupid thing won't comply with the setting for ACWAKE 0 when standby or autopoweroff is enabled (i.e. set to 1). Why does it at that point think that it should ignore ACWAKE 0?!?! That's the f'ed up thing they need to fix.

In fact, the "ridiculous" new EU standard might come handy as a good explanation in the first place, but I doubt that it describes more than a maximum standby energy consumption.

I think it really is necessary to shut down (hibernate) system to meet these requirements and the apple engineers tell the truth saying they had implemented the standby=>hibernation state change after a specific time solely for this standard.

I bet, however, the EU requirements do not state that in standby mode without AC connected system has to behave different. If it would not behave different, there would be no need to wake up on AC connect/disconnect either.

The Problem is not necessary the hibernation mode after a specified time (which is a safer state for all filevault users), but the issues around this feature:

- Mid2012 Macbooks are unresponsive after wakeup from hibernation (system seems to have fully resumed, but it is not possible to input password or move mouse cursor for a long time).

- WakeUp on AC connect/disconnect (not necessary if system would behave same on batterie/AC)

- System behaves not exactly as defined via pmset, new features of pmset are not documented in manpage

- it should be possible to configure via gui that the hibernation file is written when the lid is closed (so it would not be necessary to write to mechanical hdd while system resides in a backpack)

I tried installing 10.8.3 tonight and this is still not fixed... I was holding off on reinstalling OSX and hiding the 2.0 update but now I think I might go ahead if this is still possible. Will I be able to update to 10.8.3 without installing the 2.0 update though or will I be stuck on 10.8.2 untill Apple finally does something about this.

lci3341 wrote:

I tried installing 10.8.3 tonight and this is still not fixed... I was holding off on reinstalling OSX and hiding the 2.0 update but now I think I might go ahead if this is still possible. Will I be able to update to 10.8.3 without installing the 2.0 update though or will I be stuck on 10.8.2 untill Apple finally does something about this.

No, update 10.8.3 includes the previous changes, so even if you were to skip the 2.0 update (i.e. DL1609), the ML 10.8.3 update will still update your system to this new standard. Sorry. (I have verified this tonight, so don't doubt me. 😉)

Oliver82 wrote:

In fact, the "ridiculous" new EU standard might come handy as a good explanation in the first place, but I doubt that it describes more than a maximum standby energy consumption.

I think it really is necessary to shut down (hibernate) system to meet these requirements and the apple engineers tell the truth saying they had implemented the standby=>hibernation state change after a specific time solely for this standard.

I bet, however, the EU requirements do not state that in standby mode without AC connected system has to behave different. If it would not behave different, there would be no need to wake up on AC connect/disconnect either.

The Problem is not necessary the hibernation mode after a specified time (which is a safer state for all filevault users), but the issues around this feature:

- Mid2012 Macbooks are unresponsive after wakeup from hibernation (system seems to have fully resumed, but it is not possible to input password or move mouse cursor for a long time).

- WakeUp on AC connect/disconnect (not necessary if system would behave same on batterie/AC)

- System behaves not exactly as defined via pmset, new features of pmset are not documented in manpage

- it should be possible to configure via gui that the hibernation file is written when the lid is closed (so it would not be necessary to write to mechanical hdd while system resides in a backpack)

Actually, if you pay very close attention, the system doesn't fully return to full OS load until right before you can type in your password. Look at your clock and battery level indicators at the top of the screen, they will be frozen in time to when you went into hibernation and you'll know the OS has reloaded all it's modules back into memory when the clock flips to the correct time and then a couple of seconds later the cursor begins to blink in the password field. Yes, I've made a science out of watching the behavior of my system during this issue. 😉

BTW, for anyone interested in further realizing that this way of waking up the system when you connect/disconnect the AC adapter is nothing more than BS on the part of OSX, when you BootCamp into Windows and hibernate, you can plug and unplug the power adapter to your heart's content. No wakeup whatsoever. Just like it was in OSX prior to this BS DL1609 and now the 10.8.3 updates. Shame on Apple for being ding dongs on the way they code.

SwankPeRFection wrote:

Actually, if you pay very close attention, the system doesn't fully return to full OS load until right before you can type in your password. Look at your clock and battery level indicators at the top of the screen, they will be frozen in time to when you went into hibernation and you'll know the OS has reloaded all it's modules back into memory when the clock flips to the correct time and then a couple of seconds later the cursor begins to blink in the password field. Yes, I've made a science out of watching the behavior of my system during this issue. 😉

That's also true, but at least at my machine it is not the only delay. It takes up to additional 15 seconds before the clock and battery indicator gets refreshed and cursor in the password field starts blinking. Keyboard illumination is on at this point of time. But it takes about 20 additional seconds before i can start typing or move the mouse. No beachball in between. Sometimes, but not often, the whole process takes so much time, that the display gets shut off in between.

In console log I can see that reading the hibernation file takes between 6 and 8 seconds, but there are about 20 extra seconds between the first userspace app starts working (at my machine glowforfb) and the "USB Multitouch driver" gets initialized. It seems that keyboard is not working before this init.

Only workaround is disabling hibernation via pmset or external tools (I've tried smartsleep) - but I'm one of the few people that really like hibernation and I want it fully functional.

True, and that additional delay is normal per say. The issue is, your machine is just slower than others and that's why you're seeing this as a bigger deal than the systems that Apple intended this for. Remember that it was their intention to have this on SSD equipped systems and those drives are fast enough where this sort of thing doesn't give the user a slowness perception as easily as older systems with low RAM and slow traditional hard drives. That's another detail Apple completely overlooked.

Also, per your last sentence, it is fully functional. It works fine and as intended. My grip with it is the need for the system to wakup when the AC adapter is attached/detached from the system. That's an OSX bug/limitation. That's not necessary and with Windows hibernating in Bootcamp, it doesn't wake up, so it's an OS problem and not a hardware issue. The problem with all the waiting on your system is really just a byproduct of the speed of your system. I have a new 2012 13" with the 2.9 i7 and 16GB of memory and it takes about 20 or so seconds to wake up from hibernation. I have another idential system but with only the stock 8GB and it takes about 30-35 seconds to do the same thing. So ya, it's just the time it takes for the system to read the hibernation file, put it all back in RAM and start up all the modules from the previous state. Once that's done, then you can start using it.

SwankPeRFection wrote:

The issue is, your machine is just slower than others and that's why you're seeing this as a bigger deal than the systems that Apple intended this for.

No. How do you know that? My machine is a 2 month old 2012 MBP with I7, just as yours! And the only reason for me to not buy a ssd model was that i need space...much of it.

SwankPeRFection wrote:

The problem with all the waiting on your system is really just a byproduct of the speed of your system. I have a new 2012 13" with the 2.9 i7 and 16GB of memory and it takes about 20 or so seconds to wake up from hibernation. I have another idential system but with only the stock 8GB and it takes about 30-35 seconds to do the same thing.

The Size of the hibernation file grows with memory size. If you have two otherwise identical systems, it is illogic why the system with more memory to read and fill from disk/ssd should resume faster...i thing there is a software difference, too.

I've just made a little comparison (using a stopwatch) with my old macbook (late 2006!) with C2D, 4GB and Snow Leopard.

Boot:

old MB: 01:50; new MBP: 1:45

Resume from Hibernation:

old MB: 50s; new MBP: 1:05 (while login Window comes up after 40s, keyboard illumination starts after 55s)

My Win7 i5 non-ssd laptop at work is nearly twice as fast resuming. Of course SSD is able to speed that up. But that's no excuse for initialising keyboard driver so late in the resume process. Console log says, BTW, that reading of the hibernation file took about 6 seconds. After that the HDD-intensive part should be done.

The problem with the AC Adapter wake is one of mine, too. You wrote that using bootcamp, it is gone. System does not automatically hibernate/shutoff with bootcamp also, i assume...so it actually doesn't meet the quoted "european standard" under bootcamp...right?

What you leave running the background also has a HUGE impact on how quickly the system will resume from hibernation. Keep that in mind. I always only have Terminal, Safari, and Outlook running when I sleep the sytem, so my resumes are fast. YMMV due to what you lave running. Like I said, the other system in the house is used by someone else and wake/sleep time delay (when it's asleep only) when you plug/unplug the system is 35 seconds. Mine is less than 10 secs or so. Very quick compared to the other one. But the other has a ton of stuff left running on it. I'm a much neater/controlled user than this other one. I'm also OCD when I do things, so my processes are very repetative and the system can easily cache my patterns as part of it's normal OSX behavior.

As for the bootcamp thing, the EU standards have nothing to do with Bootcamp. It's marely an OS thing. So, with Windows running, the system power management is based on those settings. Windows 7 will wake up out of sleep and enter hibernation if left in sleep for a certain amount of time. I can't remember how many hours that's set for, but it does so on both AC and battery power without issue. The key aspect is, it doesn't wake up like the idiot OSX does when you unplug or plug it in. It stays asleep or stays hibernated (depending on what current state its in). Seamless, nice, perfect, as it should be. OSX is just too stupid to do it like that apparently.

Thanks to kuduboet for the link to that HT1757 article. They kept that quiet...

I read the EU directive and it only applies to devices on mains power in an effort to reduce mains power consumption when devices are not being used. It makes total sense, but I think the implementation by Apple has been sloppy. The 4 hour window is a bit too short. A default of 8-12 hours might be better, but you can change this thankfully.

I also note that the regulations state that the compliant changes should not be detrimental to the operation of the device. Oops...

I say oops because after the DL1609 update the system wakes and spins up the drive when you connect or disconnect the AC adaptor, even if the machine was not in hibernation. Why wake when the state is sleep and has to stay in sleep?

This now has the potential to cause serious hardware problems. No longer can you grab your sleeping mac, disconnect the power and throw it in a bag to rush off to your next class / appointment / meeting etc.

If you do, the HD will be spinning and you could damage the heads or platters by moving it. This is very bad. Still, you're covered by warranty so maybe Apple will be happy spending lots to replace hard drives. Mine is an after market drive so is not covered, so I'm understandably concerned that my drive might be damaged by sloppy coding.

Hibernate would make much more sense on battery especially if you're travelling as it protects the system better in transit. Topic for another time...

I'm going to log another job with AppleCare regarding the potential for hardware failure because that's unacceptable.

The previous points about Windows under boot camp? i can confirm them too. The issue is definitely software related and not hardware. Either Microsoft haven't updated Windows to meet the regulations yet or they've done it better for once. The jury is out...

BigGee42 wrote:

Thanks to kuduboet for the link to that HT1757 article. They kept that quiet...

I read the EU directive and it only applies to devices on mains power in an effort to reduce mains power consumption when devices are not being used. It makes total sense, but I think the implementation by Apple has been sloppy. The 4 hour window is a bit too short. A default of 8-12 hours might be better, but you can change this thankfully.

I also note that the regulations state that the compliant changes should not be detrimental to the operation of the device. Oops...

I say oops because after the DL1609 update the system wakes and spins up the drive when you connect or disconnect the AC adaptor, even if the machine was not in hibernation. Why wake when the state is sleep and has to stay in sleep?

This now has the potential to cause serious hardware problems. No longer can you grab your sleeping mac, disconnect the power and throw it in a bag to rush off to your next class / appointment / meeting etc.

If you do, the HD will be spinning and you could damage the heads or platters by moving it. This is very bad. Still, you're covered by warranty so maybe Apple will be happy spending lots to replace hard drives. Mine is an after market drive so is not covered, so I'm understandably concerned that my drive might be damaged by sloppy coding.

Hibernate would make much more sense on battery especially if you're travelling as it protects the system better in transit. Topic for another time...

I'm going to log another job with AppleCare regarding the potential for hardware failure because that's unacceptable.

The previous points about Windows under boot camp? i can confirm them too. The issue is definitely software related and not hardware. Either Microsoft haven't updated Windows to meet the regulations yet or they've done it better for once. The jury is out...

No need for the jury to be out. No Windows based system requires the system to wake up out of hibernation when the AC plug is attached/detached. A Windows system can enter hibernation at either the request of the user or based on a timeout that can be set by default timers or tailored by the end user. Windows based laptops have had this function for years, even back in XP days. This is nothing more than poor sloppy coding on Apple's part and I think it's going to boil down to just people like the two of us to keep them in check about fixing this. Trust me, I have an escalated case myself and am pushing on this issue on a weekly basis until I see it fixed.

As a side note, I also use Standby as a PM option which I've enabled so that my system hibernates after an hour on batteries and this issue with the system waking up when I plug/unplug it from power is even more annoying and unnecessary. It will get fixed one way or another... that I promiss you and everyone else impacted by this.

I also can not figure out how to solve this after looking for weeks (not continuously of course) for the solution, which seems to be to type a ridiculous string of unknown variables into the Terminal program.

I have a 13" non-retina MacBook Pro that takes 5 minutes or more to wake up first thing in the morning. I can't make this stop.

Look, this is ridiculous. I started using a Mac for many reasons, but high on that list was that I didn't want to foul around with command prompt BS... seriously?

Every year the Mac OS gets less Mac-like. I can see having that "terminal" access, but the fact that the only way to turn off this "super hibernation" feature that I never asked for and never wanted is to figure out what to type into that field (and btw, every single possibility I've found out here on the interwebz does NOT work) is an unconsionable failure of Apple to continue to respect what the Mac product has always stood for.

Am I the only one who is infuriated by this kind of stuff from Apple? They're so busy, it seems, making gobs of money on iPhones and iPads that they have abandoned the loyal users who have made them what they are today.

This "feature" NEEDS to be activated and deactivated in a control panel... not a stupid command line interface...