[AcpiSamples] SSDT-PNLF instabilities

[1alessandro1]

Good morning everyone, I'd like to track here a bug I've experienced with SSDT-PNLF after the pull request acidanthera/OpenCorePkg#284 was merged in master.

This issue has also been reported by @TonyC5 in the comments of that pull request mentioned above, but @Lorys89 kindly deleted the comment - which I find very counterproductive.

This is a screenshot of the original message and the contents are below.

TonyC5 message deleted by Lorys89

Since updating SSDT-PNLF released with OC 0.7.2 and then OC 0.7.3 on my hack, I have experienced kernel panics where logs suggest a graphics issue (com.apple.driver.AppleIntelKBLGraphics). I have reverted to SSDT-PNLF (the non-CFL version) released prior to OC 0.7.2 (none of the latest CFL changes) and haven't observed the kernel panics, but I'm still testing. My system details are below. Before I spend more time trying to diagnose and isolate the cause of the com.apple.driver.AppleIntelKBLGraphics kernel panic, does it make sense that the revised (with CFL) SSDT-PNLF could cause com.apple.driver.AppleIntelKBLGraphics kernel panics?

My system:

i5-8250u/UHD620 Kabylake R
SMBIOS: MBP14,1
Big Sur 11.6
OC 0.7.3, WEG 1.5.3, Lilu 1.5.6

panic details:

0xffffffac9be23860 : 0xffffff7faa10df53 com.apple.driver.AppleIntelKBLGraphics : ZN17IGHardwareContext4freeEv + 0x3b
0xffffffac9be23960 : 0xffffff7faa10dcf6 com.apple.driver.AppleIntelKBLGraphics : ZN17IGHardwareContext15initWithOptionsEP11IGAccelTaskRK23IGHardwareContextParamsh + 0x69a
0xffffffac9be239c0 : 0xffffff7faa10d640 com.apple.driver.AppleIntelKBLGraphics : ZN17IGHardwareContext11withOptionsEP11IGAccelTaskRK23IGHardwareContextParamsh + 0x42
0xffffffac9be239f0 : 0xffffff7faa0c064f com.apple.driver.AppleIntelKBLGraphics : ZN19IGAccelCommandQueue29createHardwareContextIfNeededEh + 0x4d
0xffffffac9be23a10 : 0xffffff7faa0c06ba com.apple.driver.AppleIntelKBLGraphics : ZN19IGAccelCommandQueue11setPriorityE28eIOAccelCommandQueuePriority + 0x44
0xffffffac9be23a40 : 0xffffff7faa9f8fca com.apple.iokit.IOAcceleratorFamily2 : ZN19IOAccelCommandQueue14updatePriorityEv + 0x64
0xffffffac9be23a60 : 0xffffff7faa9f9326 com.apple.iokit.IOAcceleratorFamily2 : _ZN19IOAccelCommandQueue27set_priority_and_backgroundE28eIOAccelCommandQueuePriorityS0 + 0xb0
0xffffffac9be23aa0 : 0xffffff801041d67e mach_kernel : ZN12IOUserClient14externalMethodEjP25IOExternalMethodArgumentsP24IOExternalMethodDispatchP8OSObjectPv + 0x1de
0xffffffac9be23af0 : 0xffffff7faa0c04be com.apple.driver.AppleIntelKBLGraphics : ZN19IGAccelCommandQueue14externalMethodEjP25IOExternalMethodArgumentsP24IOExternalMethodDispatchP8OSObjectPv + 0x1e

With @dreamwhite who has an almost identical system (same CPU, hence same iGPU) we're trying to investigate the roots of the issue... But as of now, since the original PNLF did not have this issues, we've reverted back to the original one without wasting time.

I'd keep track of this regression/bug here on this issue, since anything posted on that pull request either gets deleted or a certain user is restricted of posting for no reason, example here:

I encourage @TonyC5 to post here, and to not be afraid of his comments being deleted since it's not happening anytime soon with the issue I opened.

Thank you for your time

[1alessandro1]

@1alessandro1 , thank you for the follow-up. @Lorys89 did not delete my comment. I deleted my comment (which originally asked if SSDT-PNLF might cause the kernel panic) because the kernel panic still happens with the the non-CFL version of SSDT-PNLF. I have now reverted to OC 0.7.1 and corresponding kexts released with OC 0.7.1 (WEG, Lilu, etc) in an attempt to isolate the kernel panic.

I apologize for the false alarm - I deleted my comment, because I don't think my kernel panic is caused by SSDT-PNLF.

@TonyC5 thank you for replying, this stuff happened in the past, as demonstrated by the screenshots of the restrictions imposed without any reason.

Also, for now we could not distinguish whether this was a real issue or not. What we tested might differ from your actual setup, so I will close for now and re-open after more testing.

[Lorys89]

@1alessandro1 does not allow you to insinuate the fake! I have not deleted anything, you have become ridiculous!

[vit9696]

The panic seems to happen due to wrongly configured IGPU. I do not have access to macOS at the moment to be more precise. It is possible that the firmware has a bug causing some registers to be trashed on wake. I would rather expect the issue to be unrelated to PNLF but be caused by the tasks performed on the IGPU.

[dreamwhite]

The panic seems to happen due to wrongly configured IGPU. I do not have access to macOS at the moment to be more precise. It is possible that the firmware has a bug causing some registers to be trashed on wake. I would rather expect the issue to be unrelated to PNLF but be caused by the tasks performed on the IGPU.

I don't know if this can help but apparently doing some iGPU intensive tasks (even a stupid Zoom meeting with background effects applied), doing a sleep/wake cycle, with the acidanthera/OpenCorePkg#284 SSDT-PNLF makes the iGPU crash or even being stuck at 0.3 GHz.
At least that happened on my Catalina and Big Sur drives back in August when I tested the new SSDT-PNLF 😅.

I appreciate the effort of @Lorys89 but apparently there's something under the hood that under certain circumstances makes the iGPU misbehave...

I don't know if it's my graphics patch + BIOS settings that makes the graphics crash in those circumstances, but I've only tweaked DVMT Pre-allocated and DVMT Total Gfx Mem values and used the minimal iGPU patch for the UHD620 with the proper connectors patching, which you can consult here.

Eventually does it matter that I'm using the laptop in clamshell mode wired via HDMI port via an external monitor (virtually wired to con1 connector)?

For those who don't have a proper plist editor at hand, here's the value of framebuffer-con1-alldata: <01050900 00080000 87010000>.

Maybe it's just a matter of the UHD620 rather than the whole SSDT?

At the moment, I'm suggesting to revert the SSDT or better add some notes, so that new users, with similar configurations to ours, can revert to the """old one""" and not experience those bugs.

I wanna know your thoughts on that and eventually find a suitable way both for @Lorys89 and @1alessandro1 (as well as me and @TonyC5) who are experiencing the same bug with similar configurations.

[Lorys89]

The panic seems to happen due to wrongly configured IGPU. I do not have access to macOS at the moment to be more precise. It is possible that the firmware has a bug causing some registers to be trashed on wake. I would rather expect the issue to be unrelated to PNLF but be caused by the tasks performed on the IGPU.

I don't know if this can help but apparently doing some iGPU intensive tasks (even a stupid Zoom meeting with background effects applied), doing a sleep/wake cycle, with the acidanthera/OpenCorePkg#284 SSDT-PNLF makes the iGPU crash or even being stuck at 0.3 GHz.
At least that happened on my Catalina and Big Sur drives back in August when I tested the new SSDT-PNLF 😅.

I appreciate the effort of @Lorys89 but apparently there's something under the hood that under certain circumstances makes the iGPU misbehave...

I don't know if it's my graphics patch + BIOS settings that makes the graphics crash in those circumstances, but I've only tweaked DVMT Pre-allocated and DVMT Total Gfx Mem values and used the minimal iGPU patch for the UHD620 with the proper connectors patching, which you can consult here.

Eventually does it matter that I'm using the laptop in clamshell mode wired via HDMI port via an external monitor (virtually wired to con1 connector)?

For those who don't have a proper plist editor at hand, here's the value of framebuffer-con1-alldata: <01050900 00080000 87010000>.

Maybe it's just a matter of the UHD620 rather than the whole SSDT?

At the moment, I'm suggesting to revert the SSDT or better add some notes, so that new users, with similar configurations to ours, can revert to the """old one""" and not experience those bugs.

I wanna know your thoughts on that and eventually find a suitable way both for @Lorys89 and @1alessandro1 (as well as me and @TonyC5) who are experiencing the same bug with similar configurations.

it seems to me that on your repo this problem is prior to the date of my edit, stop saying nonsense
dreamwhite/bugtracker#14

I repeat that the. my change on the pnlf is related to the cfl and higher generations, your configuration is kbl-r is part of the code remained unchanged, now broke?by itself?
@vit9696 draw your considerations and feel free to do revert if you believe in what they say.
Kind regards.
lorys

[vit9696]

I think it is possible that the bug exists regardless of the PNLF, because I believe PNLF actions cannot directly affect the driver. However, the new PNLF may somewhat change the execution order, making this bug reproduce more often. From the disassembly it looks like IGPU virtual address space creation fails, so perhaps there is a race condition/timeout somewhere in the Apple drivers.

The original PNLF is technically faster but is impractical from the maintenance purpose. I wonder if acidanthera/WhateverGreen#91 works for you. Perhaps this route is more pragmatic.

[Lorys89]

I think it is possible that the bug exists regardless of the PNLF, because I believe PNLF actions cannot directly affect the driver. However, the new PNLF may somewhat change the execution order, making this bug reproduce more often. From the disassembly it looks like IGPU virtual address space creation fails, so perhaps there is a race condition/timeout somewhere in the Apple drivers.

The original PNLF is technically faster but is impractical from the maintenance purpose. I wonder if acidanthera/WhateverGreen#91 works for you. Perhaps this route is more pragmatic.

I have already tested the pr91 of weg, it works well in my skl+ laptops but on haswell for example it doesn't work.

[vit9696]

Well, fixing it for Haswell+ boards can be our primary task. CC @zhen-zen