Ice lake boot screen glitch seems fixed by this small WhateverGreen patch #1805
Comments
|
I think it's better to hardcode that dbuf value here in the AppleIntelPlan::updateDBUF function.
And some more information, the first updateDBUF call happens when glitch happens, and the glitch disappeared immediately when the second call happens. And I managed to get the call stack when the first and second updateDBUF call happens This is the first call This is the second As you can see, it has a lot of differences between the first and the second call stack. It's interesting that the first call is trying to set the dbuf value and the system found it's not suitable itself, and then set the optimized dbuf value through the second call. Here I attach the full boot log here. |
|
Another interesting finding, there are a lot of hardcoded dbuf values in the ice lake framebuffer too, when it's setting the optimized default value.
And I have an idea, at least we can call that AppleIntelFramebufferController::setupOptimizedDBU ourselves before the first updateDBUF call to make this patch more robust. Although I still don't know what this dbuf is. |
|
Hello, @kingo132! Thank you again for opening the issue with your ideas and mainly that fix. DBuf is display data buffer (according to some of Intel docs > https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-icllp-vol12-displayengine_0.pdf) That's where I found that explanations and some more stuff about that. Also just want to add some clarifications: here is the original (first) issue opened about that "glitch". Here you can find log with that "Failed to distribute cached..." and "Underrun..." P.S. > that patch was tested on 5 different laptops with IceLake on a board |
|
After some more tests, I think I can only get this dirty patch to live along with.
However, it works, if not, find your correct dbuf value in the boot log, hardcode that value yourself, and then it should work. This knowledge about all these intel panels or igfx or dbuf has beyond my ability. I will look into this later when I have time. |
|
the fix works great on my dell icl 💪💪 video_2021-09-29_08-46-25.mp4 |
1) Updated OC to latest master version (pre-0.7.4) + OpenLinuxBoot.efi 2) Added FeatureUnlock.kext to get my iPad mini 4 working with Sidecar 3) Updated most kexts to latest/master versions 4) Updated WhateverGreen.kext (with experimental patch to fix Ice Lake "10 seconds black screen after boot" bug). You can find details here: acidanthera/bugtracker#1805 5) Re-done some quirks in "Booter" section, still trying to get hibernation working. At least for now i only need 2 quirks to stable boot my hackintosh 6) Added some useful SSDTs (DARWIN.aml + ADP1.aml and some changes in LID.aml) to bring back "acwake" and "lidwake" to pmset settings (without that tables there are no such options in "pmset -g live" for example). 7) Maybe something more...
|
Need to check out what this register is and fix it, in my opinion, rather than try to to simulate correct value. CC @0xFireWolf. |
|
Defined here in Linux actually. Should have docs on 01.org. |
|
Those values define the position for the plane buffer. void AppleIntelPlane::updateDBUF(AppleIntelPlane* this, UInt32 start, UInt32 end)
{
// Field at 0x10C (UInt32) stores the raw value of the plane buffer config register
// Bit 0 - 10 encode the start position;
// Bit 16 - 26 encode the end position.
// The rest bits are reserved.
this->field_0x10c = start & 0x7FF | (end << 16) & 0x7FF;
// Field at 0x90 (UInt32) stores the start position
this->field_0x90 = start;
// Field at 0x94 (UInt32) stores the end position
this->field_0x94 = end;
// This function will configure the register and returns void
AppleIntelPlane::setupPlanarSurfaceDBUF(this);
}
As vit9696 mentioned above, those three member fields (at 0x90, 0x94, 0x10C) are initially set by
That being said, the root cause is somewhat deeper. Congratulation on your progress. : ) |
|
Resolved by acidanthera/WhateverGreen#92. |
Hi, WEG teams and other friends, yesterday @m0d16l14n1 send me his finding of the screen glitch when booting into the desktop with ice lake CPU.
He says it may be related to the DBuf error he saw in the boot log here.
So he wondered if we could bypass this error with some WEG patches.
I saw there're 3 conditions that can make it goes to DBuf error, they are
I tried to hook this function by WEG and printed these values
The result is here
As you can see in the screenshot, the value of v3 is first 0 and then 40 when boot, and I guess it was DBuf value. When it is 0, the DBuf error happens, and according to what @m0d16l14n1 says, the glitch happens.
You can see the DBuf error log is alongside with zero v3 value.
So I just made a small test, to hardcode that v3 value to always 40.
Some magic happens, the glitch seems gone, and some friends in Ice Lake gitter group tested it, the glitch is gone as well.
I think it's an interesting finding, but I have no knowledge about what happened, I even don't know what this DBuf is.
So I'm pushing this finding forward to ask if the WEG team or other friends could do a more robust patch based on this finding. Or at least asking for some clues about what happened and how to set a more reliable DBuf value.
Thanks to everyone who concern about this problem.
The text was updated successfully, but these errors were encountered: