[solved] Black Screen after 10.12 -> 10.12.4 update

[RehabMan]

I'm referring to 0x16260006

No guarantee that values that worked in the past will work with new versions...
Must always re-evaluate.

If you have one that works (0x16160002?) and one that doesn't (0x16260006?), then we can compare the data in each and perhaps get an idea why... Same goes for comparing one version against the next...

 

[fr0n1k]

No guarantee that values that worked in the past will work with new versions...
Must always re-evaluate.

If you have one that works (0x16160002?) and one that doesn't (0x16260006?), then we can compare the data in each and perhaps get an idea why... Same goes for comparing one version against the next...

For now, this works, but glithy, and 1024 mb:
16060000
160e0000
16160000
161e0000
16260000 (this one was laggy at the boot screen)
162b000

Doesn't work:
16220000 black screen without backlight working
16260006 black screen with backlight working

 

[RehabMan]

For now, this works, but glithy, and 1024 mb:
16060000
160e0000
16160000
161e0000
16260000 (this one was laggy at the boot screen)
162b000

Doesn't work:
16220000 black screen without backlight working
16260006 black screen with backlight working

You should attach "Problem Reporting" files for one of the ones that work (such as 0x16160000).

 

[fr0n1k]

You should attach "Problem Reporting" files for one of the ones that work (such as 0x16160000).

I will test all, and report back.. what is better to attach, with 1024 or 1536?

 

[RehabMan]

I will test all, and report back.. what is better to attach, with 1024 or 1536?

If you have an ig-platform-id that uses 1536 that works, attach that one, or the 0x16160000 one (which will be 1024).
I don't think that particular stat is that important...

Is your DVMT-prealloc directly in BIOS?
Have you checked that it is set correctly lately?

 

[fr0n1k]

If you have an ig-platform-id that uses 1536 that works, attach that one, or the 0x16160000 one (which will be 1024).
I don't think that particular stat is that important...

Is your DVMT-prealloc directly in BIOS?
Have you checked that it is set correctly lately?

dvmt set via efi, i have insydeh 20 bios, there is no other way to set prealoc for me.
It is 100% set, as i can boot 10.11.6 and 10.12 without minstole.
Here is my files+ig results.
They are differs, some brighter, some laggy, some don't boot at all, and it seems like There is a certain sequence in all files, that dont boot at all.
Your move, RehabMan.
Plus, on 10.12.4 i can reach the displays panel without EDID
Upd. Hope now you've got enough info to prevent broadwell users from update, as this will brake their stability, and we all will see the situation close to haswell users, that have got freezes..

 

[RehabMan]

dvmt set via efi, i have insydeh 20 bios, there is no other way to set prealoc for me.
It is 100% set, as i can boot 10.11.6 and 10.12 without minstole.
Here is my files+ig results.
They are differs, some brighter, some laggy, some don't boot at all, and it seems like There is a certain sequence in all files, that dont boot at all.
Your move, RehabMan.
Plus, on 10.12.4 i can reach the displays panel without EDID
Upd. Hope now you've got enough info to prevent broadwell users from update, as this will brake their stability, and we all will see the situation close to haswell users, that have got freezes..

The ioreg shows you're using 0x162b0004.
That ig-platform-id uses PWMMax of 0x1499.
You did not configure SSDT-PNLF correctly for that PWMMax (requires correct settings in SSDT-Config.aml).
See guide: https://www.tonymacx86.com/threads/...rol-using-applebacklightinjector-kext.218222/

You probably should stick with an ig-platform-id that uses PWMMax of 0xad9.
If you have one that is 0xad9 and has only a bit of lag at boot (but then it goes away), you should read the relevant topic here:

Haswell pauses/unresponsiveness shortly after boot (and after wake from sleep)
https://www.tonymacx86.com/threads/readme-common-some-unsolved-problems-in-10-12-sierra.202316/

Because it is likely that other graphics platforms have the same issue... solution is to trim the ports in the platform data to match the physical connectors present.

Also, something is wrong with your kext... in ig-platofrms and results.txt you have 0x16260006 as having PWMMax of 0x1499, but my copy here uses 0xad9. You should double check what you actually have...

 

[fr0n1k]

The ioreg shows you're using 0x192b0004.
That ig-platform-id uses PWMMax of 0x1499.
You did not configure SSDT-PNLF correctly for that PWMMax (requires correct settings in SSDT-Config.aml).
See guide: https://www.tonymacx86.com/threads/...rol-using-applebacklightinjector-kext.218222/

You probably should stick with an ig-platform-id that uses PWMMax of 0xad9.
If you have one that is 0xad9 and has only a bit of lag at boot (but then it goes away), you should read the relevant topic here:

Haswell pauses/unresponsiveness shortly after boot (and after wake from sleep)
https://www.tonymacx86.com/threads/readme-common-some-unsolved-problems-in-10-12-sierra.202316/

Because it is likely that other graphics platforms have the same issue... solution is to trim the ports in the platform data to match the physical connectors present.

Also, something is wrong with your kext... in ig-platofrms and results.txt you have 0x16260006 as having PWMMax of 0x1499, but my copy here uses 0xad9. You should double check what you actually have...

But I'm not using 1626006 or 0x192b0004
Also, I don't understand what kext are you about)

 

[RehabMan]

But I'm not using 1626006 or 0x192b0004

Typo fixed.

Also, I don't understand what kext are you about)

PWMMax is covered in the backlight guide...
If you use an ig-platform-id that doesn't use PWMMax of 0xad9 (typical Broadwell PWMmax for most ig-platform-id values), then you have to customize LMAX to indicate the PWMMax in use in SSDT-Config.

Look at the data for 0x16260000 for example... you can see the PWMMax data:
00002616 00030303 00000001 0000F000 00000040 99140000 99140000
99140000 is 0x1499 byte reversed...

Compare to, for example 0x16260006:
06002616 01030303 00002002 00005001 00000060 D90A0000 D90A0000
D90A0000 is 0x0ad9 byte reversed.

The code in SSDT-PNLF.aml assumes 0xad9 for Broadwell graphics devices.
If you use an ig-platform-id that doesn't use 0xad9, you have to set LMAX to the appropriate PWMMax as used by the framebuffer ig-platform-id...

 

[fr0n1k]

Typo fixed.



PWMMax is covered in the backlight guide...
If you use an ig-platform-id that doesn't use PWMMax of 0xad9 (typical Broadwell PWMmax for most ig-platform-id values), then you have to customize LMAX to indicate the PWMMax in use in SSDT-Config.

Look at the data for 0x16260000 for example... you can see the PWMMax data:
00002616 00030303 00000001 0000F000 00000040 99140000 99140000
99140000 is 0x1499 byte reversed...

Compare to, for example 0x16260006:
06002616 01030303 00002002 00005001 00000060 D90A0000 D90A0000
D90A0000 is 0x0ad9 byte reversed.

The code in SSDT-PNLF.aml assumes 0xad9 for Broadwell graphics devices.
If you use an ig-platform-id that doesn't use 0xad9, you have to set LMAX to the appropriate PWMMax as used by the framebuffer ig-platform-id...

Ok, there was a few, that was wit 0x0ad9..
But, as I understand, there is no way to bring 16260006 back to life?(
And the question is, what connects all the values, that don't work..