Skip to content
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

Closed
GeorgeBogosian opened this issue Oct 13, 2019 · 42 comments

Comments

@GeorgeBogosian
Copy link

@GeorgeBogosian GeorgeBogosian commented Oct 13, 2019

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

This comment has been minimized.

Copy link

@alessioprescenzo alessioprescenzo commented Oct 13, 2019

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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 13, 2019

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

This comment has been minimized.

Copy link

@Sniki Sniki commented Oct 13, 2019

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

This comment has been minimized.

Copy link

@Sher1ocks Sher1ocks commented Oct 13, 2019

latest Lilu and AppleALC are good working on latest Clover.

@Mieze

This comment has been minimized.

Copy link

@Mieze Mieze commented Oct 13, 2019

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

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 13, 2019

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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 13, 2019

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

This comment has been minimized.

Copy link

@Mieze Mieze commented Oct 13, 2019

  • 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

This comment has been minimized.

Copy link

@alessioprescenzo alessioprescenzo commented Oct 13, 2019

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

This comment has been minimized.

Copy link

@Sniki Sniki commented Oct 14, 2019

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

This comment has been minimized.

Copy link

@alessioprescenzo alessioprescenzo commented Oct 14, 2019

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

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 14, 2019

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 vit9696 reopened this Oct 14, 2019
@vit9696 vit9696 added enhancement and removed invalid labels Oct 14, 2019
@vit9696

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 14, 2019

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:

  1. Reenable HDMI audio for the IGPU
  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)
  3. Send me Lilu debug log via -liludbgall liludump=60 (this will create a file named /var/log/Lilu…txt)
  4. Send me IOReg made with IORegistryExplorer

Perhaps we can automate the detection of this.

@GeorgeBogosian

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 14, 2019

Could you please do the following:

  1. Reenable HDMI audio for the IGPU
  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)
  3. Send me Lilu debug log via -liludbgall liludump=60 (this will create a file named /var/log/Lilu…txt)
  4. 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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 14, 2019

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)
@vit9696 vit9696 closed this Oct 14, 2019
@GeorgeBogosian

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 15, 2019

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)

1 4 2_No-hda-gfx
1 4 3_No-hda-gfx

@vit9696

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 15, 2019

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

@GeorgeBogosian

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 15, 2019

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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 15, 2019

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

@GeorgeBogosian

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 15, 2019

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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 15, 2019

And where is layout-id?

@GeorgeBogosian

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@arabesc arabesc commented Oct 15, 2019

@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

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 15, 2019

Hi @arabesc

that came from the output of gfxutil

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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 15, 2019

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

This comment has been minimized.

Copy link

@arabesc arabesc commented Oct 15, 2019

@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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 15, 2019

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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 15, 2019

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:
Снимок экрана 2019-10-16 в 1 45 16

@pavelchup

This comment has been minimized.

Copy link

@pavelchup pavelchup commented Oct 16, 2019

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:
Снимок экрана 2019-10-16 в 1 45 16

Привет, отписался тут: 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

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 16, 2019

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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 16, 2019

Please redo the panic log with the boot argument added.

@pavelchup

This comment has been minimized.

Copy link

@pavelchup pavelchup commented Oct 16, 2019

Emulated NVRAM(

@alessioprescenzo

This comment has been minimized.

Copy link

@alessioprescenzo alessioprescenzo commented Oct 16, 2019

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

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 16, 2019

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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 16, 2019

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

@GeorgeBogosian

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 16, 2019

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

OK, here it is.

panic_log.txt

@vit9696

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 16, 2019

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

This comment has been minimized.

Copy link

@spnettec spnettec commented Oct 17, 2019

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

This comment has been minimized.

Copy link
Contributor

@vit9696 vit9696 commented Oct 17, 2019

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

@GeorgeBogosian

This comment has been minimized.

Copy link
Author

@GeorgeBogosian GeorgeBogosian commented Oct 17, 2019

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

This comment has been minimized.

Copy link

@TaeyonKim TaeyonKim commented Oct 17, 2019

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

This comment has been minimized.

Copy link

@Beefcat Beefcat commented Oct 17, 2019

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.

@acidanthera acidanthera locked as resolved and limited conversation to collaborators Oct 17, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.