Yosemite 10.10.2 - No wakeup from sleep

[the-darkvoid]

As per title, after updating to Yosemite 10.10.2 the laptop is not waking from sleep.
That is, it goes to sleep, tries to wake up but the display remains black / switched off.
It seems that besides the display the laptop is running fine.

Attached is my ioreg and patchmatic -extract dump.

View attachment MacBook Pro.ioreg
View attachment patchmatic-extract.zip

 

[RehabMan]

As per title, after updating to Yosemite 10.10.2 the laptop is not waking from sleep.
That is, it goes to sleep, tries to wake up but the display remains black / switched off.
It seems that besides the display the laptop is running fine.

Attached is my ioreg and patchmatic -extract dump.

View attachment 124252
View attachment 124253

Is there any difference if you only sleep the display, then wake it?

Do brightness keys (up) help?

Can you connect to it after wake? (eg. via remote desktop?)

Is it just a backlight issue (eg. if you shine a light onto the screen can you see the internal display content?)

External monitor?

Might require some work on the framebuffer... Maybe something has changed in 0xa2e0008 between the two versions.

 

[the-darkvoid]

Is there any difference if you only sleep the display, then wake it?

Same result, no display.

Do brightness keys (up) help?

No effect

Can you connect to it after wake? (eg. via remote desktop?)

Machine becomes ping-able on the network. Have not tried remote connection yet.

Is it just a backlight issue (eg. if you shine a light onto the screen can you see the internal display content?)

Nope fully dark.

External monitor?

Plugging in external monitor gives image on the external display only.

Might require some work on the framebuffer... Maybe something has changed in 0xa2e0008 between the two versions.

I will try and remove HD4600 injection, to fall back on VESA mode and give that a try.
Since that would remove any framebuffer from the equation.

 

[vbo]

Likely a framebuffer issue. Same exact behavior happened to me with a2e000a - was working perfect on 10.9, wouldn't come back after display sleep in 10.10.0. Switching to a260006 solved the issue.

 

[RehabMan]

...
I will try and remove HD4600 injection, to fall back on VESA mode and give that a try.
Since that would remove any framebuffer from the equation.

Well... sleep won't work in that scenario, so it is not really interesting. I think it is a good idea to compare the framebuffer data for 0xa2e0008 in 10.10.1 vs. 10.10.2 and see if anything has changed.

Your symptoms are very similar to problems with 0xa2e000a and 0xa26000a. There is a patch in my Clover config repo for that one (shown to work in at least two cases). Perhaps that will give you some ideas (eg. compare that data to the data at the same position of other configs, such as 0xa260006)

 

[the-darkvoid]

Ok, the majority of people seems ok with 0x0a26006.

So I am going to give that a try with QHD+

Update:

I saw a new value in AppleIntelFramebufferAzul Info.plist: lp3enable.
Wonder what that does..

 

[the-darkvoid]

10.0.1 (or possibly 10.10.0, in any case working framebuffer):

08 00 2E 0A 
01 03 03 03 00 00 00 04 00 00 20 02 
00 00 50 01 00 00 00 60 6C 05 00 00
6C 05 00 00 00 00 00 00 00 00 00 00 
00 00 08 00 02 00 00 00 30 00 00 00 
01 05 09 00 00 04 00 00 07 01 00 00 
02 04 0A 00 00 04 00 00 07 01 00 00 
FF 00 00 00 01 00 00 00 40 00 00 00 
1E 00 00 00 05 05 09 01 00 00 00 00 
00 00 00 00 80 [COLOR="#FF0000"]76[/COLOR] 04 00 00 00 00 00 
C0 [COLOR="#FF0000"]7F[/COLOR] 04 00 00 00 00 00 32 00 00 00 
00 00 00 00 0C

10.10.2:

08 00 2E 0A
01 03 03 03 00 00 00 04 00 00 20 02 
00 00 50 01 00 00 00 60 6C 05 00 00 
6C 05 00 00 00 00 00 00 00 00 00 00 
00 00 08 00 02 00 00 00 30 00 00 00 
01 05 09 00 00 04 00 00 07 01 00 00 
02 04 0A 00 00 04 00 00 07 01 00 00 
FF 00 00 00 01 00 00 00 40 00 00 00 
1E 00 00 00 05 05 09 01 00 00 00 00 
00 00 00 00 80 [COLOR="#FF0000"]86[/COLOR] 04 00 00 00 00 00 
C0 [COLOR="#FF0000"]8F[/COLOR] 04 00 00 00 00 00 32 00 00 00 
00 00 00 00 0C

Unsure if these changes are still part of the frame-buffer data itself.

 

[RehabMan]

10.0.1 (or possibly 10.10.0, in any case working framebuffer):
...
Unsure if these changes are still part of the frame-buffer data itself.

Although we don't really know the definition of these structures (no source), it does seem like this data is an "array of struct." So it is likely all data preceding the next framebuffer (0a16000c) is part of 0a2e0008.

However, the changed data is not the same data being changed by the 0a26000a/0a2e000a patch. And the 0a2e0008 already has the '1e' value (although it does have 05050901 instead of 05050000).

 

[the-darkvoid]

Yes, I compared all data from framebuffer id start until next framebuffer start.

Lets see if we use Clover to patch the 2 bytes back to the original values.

Update:

No joy, patching the original bytes back does not resolve the issue.

 

[the-darkvoid]

Tried quite a number of frame buffers.
0x0a16000c also works (as-in gives display), but the same problem occurs.

I will try reverting the AppleIntelFramebufferAzul.kext to 10.10.1, just to see if that resolves the problem.
That way the problem can be isolated to the frame buffer.

Updated:

Reverted AppleIntelFramebufferAzul.kext resolves the issue, so its indeed isolated to the framebuffer.
Scratching my head on how this can be resolved though.