-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AppleALC kernel panic #513
Comments
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. 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. |
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. |
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? |
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. |
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)? 😃 |
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. |
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:
To at least workaround a problem I added a check to AppleALC (acidanthera/AppleALC@fa4302a) to respect As an example, one could use
|
Hi @vit9696 and thank you for looking into it. I gave it a try, and adding the I attach a couple of IOReg screenshots:
|
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:
If I remove the |
And where is layout-id? |
It's there, right above it. I didn't include all the items. Here's everything under devices:
|
It seems to be an onboard audio controller, not an IGPU. |
Hi @arabesc that came from the output of gfxutil
|
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 |
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. |
Привет, отписался тут: https://applelife.ru/threads/ustanovka-macos-catalina-10-15-na-intel-pc.2944136/page-263#post-834224 |
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.
Sure, here it is.
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( |
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. |
Hi @vit9696 I did include the boot argument, you can see it in the
In my case NVRAM is native. |
@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.
|
@vit9696 Thanks. This patch is work. |
A quirk was added to OpenCore with a more robust description: |
Gave it a try and can confirm that it prevents the kernel panic. Thank you @vit9696 for this and for the explanation.
Although I'm curious about the "misconfigured hardware". Does the misconfiguration lie in the BIOS/Firmware or is it perhaps bootloader related?
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: Machine: 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
The text was updated successfully, but these errors were encountered: