Contribute
Register

[BUG] Black screen 3 minutes after booting, CoffeeLake UHD 630

Update: Tried with a framebuffer that has Camellia disabled(0x3e9b0000) but the issue still remains. But Vit says it is working for @headkaze. We'll have to wait for headkaze to confirm.

By the meantime you folks can test and see if it works for you. I am attaching the latest WEG as of now.

Please make sure:
  • You use a framebuffer that has Camellia disabled.
  • Do not have IntelMaxBacklight set to 120000 in config.plist
  • Use igfxcflbklt=1 boot-arg (without leading dash)
  • Inject enable-cfl-backlight-fix property with value 1 on IGPU.
Regards
 

Attachments

  • WhateverGreen.kext.zip
    205.2 KB · Views: 78
Update: Tried with a framebuffer that has Camellia disabled(0x3e9b0000) but the issue still remains. But Vit says it is working for @headkaze. We'll have to wait for headkaze to confirm.

By the meantime you folks can test and see if it works for you. I am attaching the latest WEG as of now.

Please make sure:
  • You use a framebuffer that has Camellia disabled.
  • Do not have IntelMaxBacklight set to 120000 in config.plist
  • Use igfxcflbklt=1 boot-arg (without leading dash)
  • Inject enable-cfl-backlight-fix property with value 1 on IGPU.
Regards

Did all as stated. Could not get my laptop to book with the igfxcflbklt=1 bootflag. I got a CFL Framebuffer kernel panic (attached picture of it). But using the other bootflags igfxcflbklt=opcode or igfxcflbklt=wrap allowed me to boot. Both with a black screen, though. So no change to the issue on my end.

PR files attached.
 

Attachments

  • IMG_20181211_130201.jpg
    IMG_20181211_130201.jpg
    2.8 MB · Views: 101
  • debug_8348.zip
    1.9 MB · Views: 74
During some unrelated testing I figured out why using Lilu to hook AppleIntelFramebufferController::WriteRegister32 fails (causes seemingly-random kernel panics).

When Lilu routes a function, it writes an absolute jmp to the start of the original function body. This instruction takes (iirc) 9 bytes, so it has to relocate the instructions that would be overwritten to its trampoline memory region. This works fine for most functions, but AppleIntelFramebufferController::WriteRegister32 is compiled with llvm code coverage instrumentation turned on and increments a block-hit counter immediately at start -- within those first 9 bytes. The block-hit counter that it increments is addressed RIP-relative (instruction is inc [rip + 0xwhatever]), so when that instruction gets moved into the trampoline region it's no longer incrementing the counter but some random qword in kernel memory.

This would be fixable either by having WEG NOP out that first inc instruction before routing WriteRegister32, or by patching Lilu to fix RIP-relative displacement on instructions that it moves to the trampoline region. Then we could get away with just hooking WriteRegister32 to fix the backlight frequency register math and avoid the complicated/failure-prone math code patches.
 
Did all as stated. Could not get my laptop to book with the igfxcflbklt=1 bootflag.
igfxcflbklt=1 boot flag is the only one that works now.

Vit had a look at your KP (which is actually an assertion) and as you can see it's unrelated to the patch. It's related to DVMT.
kprintf(
"%s",
"/Library/Caches/com.apple.xbs/Sources/GPUDriversIntel/GPUDriversIntel-10.36.22/Common/IONDRV/Intel/CFL/AppleIntelF"
"ramebuffer/AppleIntelController.cpp:27883 Assertion failed: minStolenSize <= fStolenMemorySize \n");
panic(
"assertmsg@/Library/Caches/com.apple.xbs/Sources/GPUDriversIntel/GPUDriversIntel-10.36.22/Common/IONDRV/Intel/CFL/A"
"ppleIntelFramebuffer/AppleIntelController.cpp:27883");
 
igfxcflbklt=1 boot flag is the only one that works now.

Vit had a look at your KP (which is actually an assertion) and as you can see it's unrelated to the patch. It's related to DVMT.
So this issue is fixed? Can you suggest me what else to try?

I am currently using the latest WEG from upstream with all the properties and SSDT-PNLF.

I am also making sure that I am using a framebuffer with Camellia disabled (0x3E9B0000)

What else should I try?

P.S: For all those using WEG from post #325, you may remove AppleBacklightFixup.kext as it is now included in WEG. Patching is done automatically, no configuration required.

Regards
 
During some unrelated testing I figured out why using Lilu to hook AppleIntelFramebufferController::WriteRegister32 fails (causes seemingly-random kernel panics).

When Lilu routes a function, it writes an absolute jmp to the start of the original function body. This instruction takes (iirc) 9 bytes, so it has to relocate the instructions that would be overwritten to its trampoline memory region. This works fine for most functions, but AppleIntelFramebufferController::WriteRegister32 is compiled with llvm code coverage instrumentation turned on and increments a block-hit counter immediately at start -- within those first 9 bytes. The block-hit counter that it increments is addressed RIP-relative (instruction is inc [rip + 0xwhatever]), so when that instruction gets moved into the trampoline region it's no longer incrementing the counter but some random qword in kernel memory.

This would be fixable either by having WEG NOP out that first inc instruction before routing WriteRegister32, or by patching Lilu to fix RIP-relative displacement on instructions that it moves to the trampoline region. Then we could get away with just hooking WriteRegister32 to fix the backlight frequency register math and avoid the complicated/failure-prone math code patches.
Please have a look at https://github.com/acidanthera/WhateverGreen/pull/11#issuecomment-446362280
 
igfxcflbklt=1 boot flag is the only one that works now.

Vit had a look at your KP (which is actually an assertion) and as you can see it's unrelated to the patch. It's related to DVMT.
Welp, looks like I'm breaking down and modding my BIOS. Was trying to avoid that. I will do so and adjust my DVMT settings manually, remove the patch and report back.
 
igfxcflbklt=1 boot flag is the only one that works now.

Vit had a look at your KP (which is actually an assertion) and as you can see it's unrelated to the patch. It's related to DVMT.

So I went and unlocked my BIOS, changed my DVMT to 64MB (the max this laptop allows), removed the DVMT patch from my config.plist and tried the igfxcflbklt=1 and I was able to boot now, but out of 6 boots only one had backlight working, the other 5 were all black screen until I put the laptop to sleep or waited 3 minutes.

Unless I missed something else, the update doesn't seem to be working on my end :thumbdown

Attached update PR files.
 

Attachments

  • debug_9516.zip
    2.2 MB · Views: 69
For me there is only a slight problem. During the installation of Mojave the brightness was fine but then, when in post-install, I noticed that the brightness was very low compared to before. I can change the brightness in setting but the maximun is not like it should be.
 

Attachments

  • debug_29656.zip
    1.5 MB · Views: 66
For me there is only a slight problem. During the installation of Mojave the brightness was fine but then, when in post-install, I noticed that the brightness was very low compared to before. I can change the brightness in setting but the maximun is not like it should be.
No more black screen issue now?
 
Back
Top