AppleALC kernel panic #513

GeorgeBogosian · 2019-10-13T14:45:40Z

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

alessioprescenzo · 2019-10-13T15:01:17Z

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 .

vit9696 · 2019-10-13T15:18:06Z

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.

Sniki · 2019-10-13T15:31:56Z

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.

Sher1ocks · 2019-10-13T15:36:35Z

latest Lilu and AppleALC are good working on latest Clover.

Mieze · 2019-10-13T15:55:36Z

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

GeorgeBogosian · 2019-10-13T16:29:50Z

Hi everyone and thanks a lot for taking a look.

Some clarifications:

This is a desktop PC with a Coffee Lake CPU (8700K) running on a Z370 motherboard (Asus Prime Z370-A).
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.

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.

vit9696 · 2019-10-13T16:43:20Z

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.

Mieze · 2019-10-13T16:47:49Z

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?

alessioprescenzo · 2019-10-13T16:54:34Z

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.

Sniki · 2019-10-14T08:50:39Z

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.

alessioprescenzo · 2019-10-14T10:01:38Z

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 :)

GeorgeBogosian · 2019-10-14T14:19:37Z

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)? 😃

vit9696 · 2019-10-14T14:27:39Z

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:

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

Perhaps we can automate the detection of this.

GeorgeBogosian · 2019-10-14T17:45:25Z

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.

Lilu_1.3.8_19.0.txt
IOReg.zip

vit9696 · 2019-10-14T23:17:45Z

Thank you.

So, the following holds true:

Recent Macs with external (AMD) GPU like iMac18,3 use No-hda-gfx to signalise that IGPU digital audio is to be ignored
Injecting hda-gfx is required for IGPU digital audio to work, and this is what is done on IGPU-only Macs
AppleALC injects hda-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 (acidanthera/AppleALC@fa4302a) 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)

GeorgeBogosian · 2019-10-15T13:04:13Z

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:

The first is 1.4.2 with the source changes you asked me to make (audio works)
The second is 1.4.3 with the added No-hda-gfx (audio disabled)

vit9696 · 2019-10-15T13:23:07Z

Which audio are we talking about? I would expect HDEF (analog) audio to work, and digital audio to not work in this case.

GeorgeBogosian · 2019-10-15T13:45:33Z

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).

vit9696 · 2019-10-15T13:52:11Z

That sounds very strange, are you sure you made no mistake?

GeorgeBogosian · 2019-10-15T15:08:39Z

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.

vit9696 · 2019-10-15T15:24:51Z

And where is layout-id?

GeorgeBogosian · 2019-10-15T15:39:44Z

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>

arabesc · 2019-10-15T21:13:01Z

@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.

GeorgeBogosian · 2019-10-15T21:58:06Z

Hi @arabesc

that came from the output of gfxutil

gfxutil -f HDEF
DevicePath = PciRoot(0x0)/Pci(0x1f,0x3)

vit9696 · 2019-10-15T22:22:27Z

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.

arabesc · 2019-10-15T22:34:58Z

@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

vit9696 · 2019-10-15T22:38:07Z

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.

vit9696 · 2019-10-15T22:45:42Z

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:

pavelchup · 2019-10-16T10:38:06Z

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, но после сна перезагрузился...

GeorgeBogosian · 2019-10-16T10:39:04Z

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.

vit9696 · 2019-10-16T10:51:14Z

Please redo the panic log with the boot argument added.

pavelchup · 2019-10-16T10:57:09Z

Emulated NVRAM(

alessioprescenzo · 2019-10-16T14:34:16Z

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.

GeorgeBogosian · 2019-10-16T15:33:22Z

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.

vit9696 · 2019-10-16T16:05:03Z

@GeorgeBogosian I meant with setpowerstate_panic=0 in addition to the other ones.

GeorgeBogosian · 2019-10-16T16:53:52Z

@GeorgeBogosian I meant with setpowerstate_panic=0 in addition to the other ones.

OK, here it is.

panic_log.txt

vit9696 · 2019-10-16T18:43:13Z

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

spnettec · 2019-10-17T01:57:12Z

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.

vit9696 · 2019-10-17T08:44:04Z

A quirk was added to OpenCore with a more robust description:
acidanthera/OpenCorePkg@b393b05

GeorgeBogosian · 2019-10-17T14:45:21Z

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.

TaeyonKim · 2019-10-17T16:41:12Z

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.

Beefcat · 2019-10-17T17:13:15Z

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:

IOREG.zip
Lilu_1.3.8_19.0.txt

PS: not sure how to generate panic file and what to set to allow it to generate panic ? Happy to share that as well.

vit9696 added help wanted Extra attention is needed invalid This doesn't seem right project:alc labels Oct 13, 2019

Andrey1970AppleLife closed this as completed Oct 14, 2019

vit9696 reopened this Oct 14, 2019

vit9696 added enhancement New feature or request and removed invalid This doesn't seem right labels Oct 14, 2019

vit9696 closed this as completed Oct 14, 2019

acidanthera locked as resolved and limited conversation to collaborators Oct 17, 2019

AppleALC kernel panic #513

AppleALC kernel panic #513

Comments

GeorgeBogosian commented Oct 13, 2019

alessioprescenzo commented Oct 13, 2019

vit9696 commented Oct 13, 2019

Sniki commented Oct 13, 2019 • edited Loading

Sher1ocks commented Oct 13, 2019

Mieze commented Oct 13, 2019 • edited Loading

GeorgeBogosian commented Oct 13, 2019

vit9696 commented Oct 13, 2019

Mieze commented Oct 13, 2019

alessioprescenzo commented Oct 13, 2019 • edited Loading

Sniki commented Oct 14, 2019

alessioprescenzo commented Oct 14, 2019

GeorgeBogosian commented Oct 14, 2019

vit9696 commented Oct 14, 2019

GeorgeBogosian commented Oct 14, 2019

vit9696 commented Oct 14, 2019

GeorgeBogosian commented Oct 15, 2019

vit9696 commented Oct 15, 2019

GeorgeBogosian commented Oct 15, 2019

vit9696 commented Oct 15, 2019

GeorgeBogosian commented Oct 15, 2019 • edited Loading

vit9696 commented Oct 15, 2019

GeorgeBogosian commented Oct 15, 2019

arabesc commented Oct 15, 2019 • edited Loading

GeorgeBogosian commented Oct 15, 2019

vit9696 commented Oct 15, 2019

arabesc commented Oct 15, 2019

vit9696 commented Oct 15, 2019

vit9696 commented Oct 15, 2019

pavelchup commented Oct 16, 2019 • edited Loading

GeorgeBogosian commented Oct 16, 2019

vit9696 commented Oct 16, 2019

pavelchup commented Oct 16, 2019

alessioprescenzo commented Oct 16, 2019

GeorgeBogosian commented Oct 16, 2019

vit9696 commented Oct 16, 2019

GeorgeBogosian commented Oct 16, 2019

vit9696 commented Oct 16, 2019

spnettec commented Oct 17, 2019

vit9696 commented Oct 17, 2019

GeorgeBogosian commented Oct 17, 2019

TaeyonKim commented Oct 17, 2019 • edited Loading

Beefcat commented Oct 17, 2019

Sniki commented Oct 13, 2019 •

edited

Loading

Mieze commented Oct 13, 2019 •

edited

Loading

alessioprescenzo commented Oct 13, 2019 •

edited

Loading

GeorgeBogosian commented Oct 15, 2019 •

edited

Loading

arabesc commented Oct 15, 2019 •

edited

Loading

pavelchup commented Oct 16, 2019 •

edited

Loading

TaeyonKim commented Oct 17, 2019 •

edited

Loading