Closed GeorgeBogosian closed 5 years ago
This issues was also discussed here: https://www.tonymacx86.com/threads/help-applealc-kernel-panic-after-catalina-update.284654/ which contains various information.
The bug seem to affect Hardwell processor and it's due to something that manage HD Audio through hdmi/dp.
A thing that might be useful, this don't happen with builds before 1.3.0 .
Well, to me it looks like activating HDMI audio results in some hang in AppleHDA due to some problem in your digital audio controller (8086:A2F0:0) configuration. The mode choice (iMac18,1) and the rest looks like a mess.
Most likely this is just some bootloader configuration/ACPI problem, as our Haswell setups work fine. Perhaps the simplest workaround for you is to inject some unsupported device-id/class-code and disable the digital audio controller. Another way could be returning zero from _STA method.
I will leave the issue open for some time to let other people see it, but it is not like we are going to investigate it for a couple of reasons:
No issues here either, i have a Lenovo ThinkPad X240 which is Haswell generation. @GeorgeBogosian setup looks like a barbaric mess, no wonder it panics
Also users of my laptop guides updated to Catalina as well and reported no issues whatsoever.
latest Lilu and AppleALC are good working on latest Clover.
AppleHDAHDMI_DPDriver::setPowerState(0xffffff8059516a00 : 0xffffff7f8deaf730, 0 -> 1) timed out after 10172 ms"@/BuildRoot/Library/Caches/com.apple.xbs/Sources/xnu/xnu-6153.11.26/iokit/Kernel/IOServicePM.cpp:5302
This error message reminds of an issue I had a year ago. You might want to have a look at https://www.insanelymac.com/forum/topic/328549-tracing-back-the-amd-gpu-wakeup-issue-to-its-origin/?do=findComment&comment=2647358
Hi everyone and thanks a lot for taking a look.
Some clarifications:
Unfortunately, I'm not as qualified to recognize the mess you see or how to tidy it up. I used the latest versions of everything with as few Clover patches/options enabled as possible (to my knowledge) and with just a few injected kexts.
If there is nothing to be fixed, I guess I'll have to give OpenCore a try. Broken sleep is a huge pain from my part.
Best Regards.
Huh, so that's not Haswell? Then @Mieze might actually be right. 8086:A2F0(!) is an IGPU device, yet it has digital audio class code, which makes no sense to me. Setting No-hda-gfx is possibly the hack Apple uses itself to avoid such collision.
- I don't use HDMI at all. A single monitor is connected via DP.
- I don't have a dedicated GPU. iGPU only (UHD 630).
- I use Clover v2.5k_r5093 (tried v2.5k_r5096 too).
- Everything worked fine under Mojave.
Same situation here, only one display connected via DP, but with regard to AppleHDAHDMI_DPDriver there's not much difference between IGPU and a dGPU. Both use the same driver.
Have you considered the possibility that Apple may have changed something in Catalina?
Well, to me it looks like activating HDMI audio results in some hang in AppleHDA due to some problem in your digital audio controller (8086:A2F0:0) configuration. The mode choice (iMac18,1) and the rest looks like a mess.
Most likely this is just some bootloader configuration/ACPI problem, as our Haswell setups work fine. Perhaps the simplest workaround for you is to inject some unsupported device-id/class-code and disable the digital audio controller. Another way could be returning zero from _STA method.
I will leave the issue open for some time to let other people see it, but it is not like we are going to investigate it for a couple of reasons:
- there is nothing in AppleALC to fix, the issue is on the hardware configuration layer.
- the setup looks especially messed up and most likely built with Clover, which we do not support.
He posted under my thread that he opened an issue, I thought he was talking about our problem in the post. Sincerely I don't think that my Clover plist is a mess, I even cleaned it up trying to fix this problem. My device worked flawlessly with Mojave but hangs after sleep with Catalina and it's an 8086:c0c0 which should be supported, right?
Edit: the list of things I tried is uncomfortably long, and I don't know where else to look for fixing my issue, I seriously scraped forums over forums.
Well, to me it looks like activating HDMI audio results in some hang in AppleHDA due to some problem in your digital audio controller (8086:A2F0:0) configuration. The mode choice (iMac18,1) and the rest looks like a mess. Most likely this is just some bootloader configuration/ACPI problem, as our Haswell setups work fine. Perhaps the simplest workaround for you is to inject some unsupported device-id/class-code and disable the digital audio controller. Another way could be returning zero from _STA method. I will leave the issue open for some time to let other people see it, but it is not like we are going to investigate it for a couple of reasons:
- there is nothing in AppleALC to fix, the issue is on the hardware configuration layer.
- the setup looks especially messed up and most likely built with Clover, which we do not support.
He posted under my thread that he opened an issue, I thought he was talking about our problem in the post. Sincerely I don't think that my Clover plist is a mess, I even cleaned it up trying to fix this problem. My device worked flawlessly with Mojave but hangs after sleep with Catalina and it's an 8086:c0c0 which should be supported, right?
Edit: the list of things I tried is uncomfortably long, and I don't know where else to look for fixing my issue, I seriously scraped forums over forums.
Im too busy recently with other projects and life in general, but i added this into my todo list and since im a mod at tonymacx86 i will answer and help you there. Then after figuring out the problem we continue here if no solution is found.
Im too busy recently with other projects and life in general, but i added this into my todo list and since im a mod at tonymacx86 i will answer and help you there. Then after figuring out the problem we continue here if no solution is found.
Thanks for your time, really appreciated. See you on tonymacx86 then :)
Hi everyone and thank you for your input,
I managed to resolve this by disabling HDMI audio for the iGPU.
The issue, as I understand it, is that a property "hda-gfx" is erroneously injected in the HDEF object and should be replaced with "No-hda-gfx". This causes kernel panic, on wake from sleep, under Catalina.
Right now, the solution is to disable HDMI audio for the iGPU, either through a DSDT patch that implements the above change or through the iDisplay Audio Disconnect variable at the BIOS. I used RU.efi to do the latter.
As I mentioned, I'm not qualified to know if or what needs to be fixed/patched for this issue to be resolved (AppleALC, WhateverGreen, bootloader, …), I'm just detailing my findings in case they are helpful.
Thank you Mieze for correctly identifying the problem and pointing to the right direction. Where should I send the crate of beer (or any other beverage you enjoy)? :smiley:
I do not think it is injected into HDEF but rather IGPU itself, and I believe we need some collaboration between this and AppleALC. Could you please do the following:
Perhaps we can automate the detection of this.
Could you please do the following:
- Reenable HDMI audio for the IGPU
- Temporarily replace hda-gfx with No-hda-gfx in AppleALC source code to avoid the kernel panic (https://github.com/acidanthera/AppleALC/blob/master/AppleALC/kern_alc.cpp, this file)
- Send me Lilu debug log via -liludbgall liludump=60 (this will create a file named /var/log/Lilu…txt)
- Send me IOReg made with IORegistryExplorer
Sure, happy to help.
I'm attaching the requested files and I can confirm that with the source code change, there is no longer a KP after wake.
Thank you.
So, the following holds true:
No-hda-gfx
to signalise that IGPU digital audio is to be ignoredhda-gfx
is required for IGPU digital audio to work, and this is what is done on IGPU-only Macshda-gfx
on IGPU-only configurations like it is done on real Macs, but due to some bug in your firmwares an error message (or a kernel panic as of 10.15) is spit upon loading from AppleHDAHDMI_DPDriver::setPowerState
.To at least workaround a problem I added a check to AppleALC (https://github.com/acidanthera/AppleALC/commit/fa4302ab970a4ddf5af46bd771a7a0c2f7f6eaed) to respect No-hda-gfx
property in HDEF and not inject hda-gfx
when it is present.
As an example, one could use DeviceProperties
in OpenCore to add No-hda-gfx
property to HDEF: 8 zero bytes as suggested by @Mieze above. Figuring device path for HDEF is as easy as running gfxutil (hosted here), e.g.:
$gfxutil -f HDEF
DevicePath = PciRoot(0x0)/Pci(0x1b,0x0)
Hi @vit9696 and thank you for looking into it.
I gave it a try, and adding the No-hda-gfx
device property (tried with values: empty, 8 zero bytes and onboard-1) does indeed prevent the injection of hda-gfx
, but unfortunately it also seems to completely disable audio.
I attach a couple of IOReg screenshots:
No-hda-gfx
(audio disabled)
Which audio are we talking about? I would expect HDEF (analog) audio to work, and digital audio to not work in this case.
Yes, I meant analog audio. The volume icon in the menu bar is greyed out.
Unfortunately I don't have a way to test digital audio (monitor has no speakers).
That sounds very strange, are you sure you made no mistake?
Yes, I'm pretty sure; I triple checked.
Compiled AppleALC with the latest changes and added in config.plist the following:
<key>Properties</key>
<dict>
<key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
<dict>
<key>No-hda-gfx</key>
<data>
AAAAAAAAAAA=
</data>
</dict>
</dict>
No-hda-gfx
with 8 zero bytes appears under HDEF, hda-gfx
is no longer there (you can see in the screenshots that several other properties are also missing), but analog audio is disabled ("No output devices found").
If I remove the No-hda-gfx
property, audio works again, but panics again on wake.
And where is layout-id?
It's there, right above it. I didn't include all the items. Here's everything under devices:
<key>Devices</key>
<dict>
<key>Audio</key>
<dict>
<key>Inject</key>
<integer>7</integer>
<key>ResetHDA</key>
<false/>
</dict>
<key>Properties</key>
<dict>
<key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
<dict>
<key>No-hda-gfx</key>
<data>
AAAAAAAAAAA=
</data>
</dict>
</dict>
<key>USB</key>
<dict>
<key>AddClockID</key>
<false/>
<key>FixOwnership</key>
<false/>
<key>HighCurrent</key>
<true/>
<key>Inject</key>
<true/>
</dict>
<key>UseIntelHDMI</key>
<false/>
</dict>
@GeorgeBogosian
<key>PciRoot(0x0)/Pci(0x1f,0x3)</key>
<dict>
<key>No-hda-gfx</key>
It seems to be an onboard audio controller, not an IGPU.
Hi @arabesc
that came from the output of gfxutil
gfxutil -f HDEF
DevicePath = PciRoot(0x0)/Pci(0x1f,0x3)
I do not know how that Clover Inject works, we do not support it. As far as I know it randomly adds other properties, so I would request somebody test with OpenCore instead.
@GeorgeBogosian
you are right, I've thought that No-hda-gfx
should been written for IGPU device
I've written it for HDEF device, updated AppleALC.kext to the latest (1.4.3) version, and there is no more panics after sleep
In the meanwhile, could you please send me the panic log with keepsyms=1 in boot arguments? So that I can see the whole stack trace as normal.
macOS 10.15 supports a dedicated boot argument setpowerstate_panic=0
, which allows one to disable this kernel panic. Perhaps it is the preferrable solution for some people:
macOS 10.15 supports a dedicated boot argument
setpowerstate_panic=0
, which allows one to disable this kernel panic. Perhaps it is the preferrable solution for some people:
Привет, отписался тут: https://applelife.ru/threads/ustanovka-macos-catalina-10-15-na-intel-pc.2944136/page-263#post-834224 Добавил setpowerstate_panic=0, вернул AppleALC 1.4.2, и убрал no-hda-gfx свойство в Properties, но после сна перезагрузился...
I do not know how that Clover Inject works, we do not support it. As far as I know it randomly adds other properties, so I would request somebody test with OpenCore instead.
I'll give OpenCore a try later and report back. Eventually I'll have to move away from Clover, so I guess better sooner than later.
In the meanwhile, could you please send me the panic log with keepsyms=1 in boot arguments? So that I can see the whole stack trace as normal.
Sure, here it is. panic_log.txt
macOS 10.15 supports a dedicated boot argument
setpowerstate_panic=0
, which allows one to disable this kernel panic. Perhaps it is the preferrable solution for some people:
Nice find! I tried it, but unfortunately it doesn't seem to prevent the KP on wake.
Please redo the panic log with the boot argument added.
Emulated NVRAM(
macOS 10.15 supports a dedicated boot argument
setpowerstate_panic=0
, which allows one to disable this kernel panic. Perhaps it is the preferrable solution for some people
This DON'T prevents the KP to happen. I also tried with FAKE_PCI_ID for HDMI audio, and that made my IORegistry under HDAU almost empty, and as expected no KP but no audio via HDMI, I suppose that fake_pci_id is not needed (when I remove it my HDAU in registry becomes normal again but with the wake KP problem).
Regarding the no_hda_gfx, it's not applicable in my case so I haven't even tried.
Hope to find a solution.
Please redo the panic log with the boot argument added.
Hi @vit9696
I did include the boot argument, you can see it in the Boot args:
list. Perhaps you need the .panic log under /Library/Logs/DiagnosticReports
?
Emulated NVRAM(
In my case NVRAM is native.
@GeorgeBogosian I meant with setpowerstate_panic=0 in addition to the other ones.
@GeorgeBogosian I meant with setpowerstate_panic=0 in addition to the other ones.
OK, here it is.
Indeed they did not add an argument to release kernels, and enforced the kernel panic for all Apple-made kexts. Ok, in this case the following kernel patch may suffice as a workaround.
Find: 63 6F 6D 2E 61 70 70 6C 65 00 5F 5F 6B 65 72 6E 65 6C 5F 5F 00
Repl: 6E 6F 74 2E 61 70 70 6C 65 00 5F 5F 6B 65 72 6E 65 6C 5F 5F 00
Indeed they did not add an argument to release kernels, and enforced the kernel panic for all Apple-made kexts. Ok, in this case the following kernel patch may suffice as a workaround.
Find: 63 6F 6D 2E 61 70 70 6C 65 00 5F 5F 6B 65 72 6E 65 6C 5F 5F 00 Repl: 6E 6F 74 2E 61 70 70 6C 65 00 5F 5F 6B 65 72 6E 65 6C 5F 5F 00
@vit9696 Thanks. This patch is work.
A quirk was added to OpenCore with a more robust description: https://github.com/acidanthera/OpenCorePkg/commit/b393b0594ef92e9afd61fa3755d185eb8cba39a4
Indeed they did not add an argument to release kernels, and enforced the kernel panic for all Apple-made kexts. Ok, in this case the following kernel patch may suffice as a workaround.
Find: 63 6F 6D 2E 61 70 70 6C 65 00 5F 5F 6B 65 72 6E 65 6C 5F 5F 00 Repl: 6E 6F 74 2E 61 70 70 6C 65 00 5F 5F 6B 65 72 6E 65 6C 5F 5F 00
Gave it a try and can confirm that it prevents the kernel panic. Thank you @vit9696 for this and for the explanation.
An additional security measure was added to macOS Catalina (10.15) causing kernel panic on power change timeout for Apple drivers. Sometimes it may cause issues on misconfigured hardware, notably digital audio, which sometimes fails to wake up.
Although I'm curious about the "misconfigured hardware". Does the misconfiguration lie in the BIOS/Firmware or is it perhaps bootloader related?
2. Temporarily replace hda-gfx with No-hda-gfx in AppleALC source code to avoid the kernel panic (https://github.com/acidanthera/AppleALC/blob/master/AppleALC/kern_alc.cpp, this file)
It is interesting though, that the above seemed to prevent the KP as well.
I am a bit late in this discussion. But I'd like to provide my 2 cents here. Can we use a boot argument instead of using the "No-hda-gfx" property? It's not easy to set this property. And when using Clover, setting this property (or any other property names) disables the audio for unknown reason. Also, as a user, I am not in favour of touching the original kernel binary. For users using the Haswell chipset with HDMI / DP, I don't think there is an easy solution for them to address this issue yet.
Hi Guys, hope this is the correct forum to add more details.
I have a Haswell board with similar problem (no wake after sleep - screen does not come on)
I have added the above kernel patch but had no LUCK with it.
Problem: After wake from sleep my machine does not restart. Instead the cpu starts up and the GPU RX 580 also start up.
Machine: GA-Z97x Gaming 5 with i7-4790K CPU AMD Radeon RX 580 with 2 displays (one connected to hdmi and another via DP)
Attached is my debug files:
PS: not sure how to generate panic file and what to set to allow it to generate panic ? Happy to share that as well.
Hi, under Catalina (19A583) and with latest AppleALC (1.4.2) and Lilu (1.3.8) I'm getting kernel panics when waking from sleep.
I'm attaching the debug log and the kernel panic details.
Many thanks
debug.txt Problem_Details_and_System_Configuration.txt