AMD Rayon R7 5800H Install Monterey kernel Panic

[zxc2689963]

Hello everyone, the Monterey kernel panic problem has been solved for AMD R7 5800H notebook installation. It is a great thing that the CPU can now run on 8 cores. Thank you guys very much.Thank them for discovering the problem and providing kernel patches @ExtremeX@Visual

Brand: Lenovo
Model: Legion 5 6th Gen
CPU: AMD Ryzen 7 5800h
GPU: AMD Radeon RX 6600m 8GB ( Separate GPU mode)
HDD: Samsung SSD 970 EVO Plus 1TB (1000 GB, PCI-E 3.0 x4)
WDS500G3X0C-00SJG0 (500 GB, PCI-E 3.0 x4)
Network: RealTek Semiconductor RTL8168/8111 PCI-E Gigabit Ethernet NIC
Intel(R) Wi-Fi 6E AX210 160MHz
Ram: x2 8GB 3200mhz ddr4
Display: 15.6 1080p 165HZ

Updated October 5, 2023
Problems solved:
1. You do not need to disable XHCI
2. The microphone problem is rectified
3. Monitor brightness can be adjusted, only in Ventura

Unresolved issues:
Failure to wake from sleep

 

[ExtremeXT]

@scyte
Send me the SysReport folder zipped created by OpenCore in your EFI partition.

 

[ExtremeXT]

So I noticed that I did a lot of typos in SSDT-CPUR, which would certainly explain the stall/panic near AppleACPICPU. Please try this revised EFI. If it's still getting stuck try removing npci=0x3000 from boot-args. The SysReport folder created on the root of your USB drive would also be useful, since I need to take a value from FACP for the SSDT.

- ExtremeXT

 

[Middleman]

So I noticed that I did a lot of typos in SSDT-CPUR, which would certainly explain the stall/panic near AppleACPICPU. Please try this revised EFI. If it's still getting stuck try removing npci=0x3000 from boot-args. The SysReport folder created on the root of your USB drive would also be useful, since I need to take a value from FACP for the SSDT.

- ExtremeXT

Yes, and that's why I created a new SSDT-CPUR-5800HX-rev2 for the new EFI I posted earlier today. Because the one used by @scyte was likely based on
@zxc2689963's build which I found was using a different CPU naming scheme compared to other Ryzen's I'd seen. This is why it isn't recognised by the OS. In the old SSDT-CPUR they were defined as processors. In the newer chips they are defined as devices.

 

[ExtremeXT]

Yes, and that's why I created a new SSDT-CPUR-5800HX-rev2 for the new EFI I posted earlier today. Because the one used by @scyte was likely based on
@zxc2689963's build which I found was using a different CPU naming scheme compared to other Ryzen's I'd seen. This is why it isn't recognised by the OS. In the old SSDT-CPUR they were defined as processors. In the newer chips they are defined as devices.

Yes, newer ACPI table formats use a Device definition instead of a Processor definition. My SSDT creates fake Processor devices for macOS to play with.

 

[ExtremeXT]

Hi, if it's still stuck, try this new SSDT-CPUR.

- ExtremeXT

 

[zty199]

Hi, if it's still stuck, try this new SSDT-CPUR.

- ExtremeXT

I tried your latest EFI and SSDT-CPUR.aml, and I was trying to load Monterey installer. But I still need cpus=1 or there will be kernel panic.

After I add cpus=1 in boot-args, I thought it still just stuck at somewhere after PCI configuration. Not sure what happened since there is no SysReport.zip generated in EFI folder in my USB installer.

I also tried to load Big Sur installer, it doesn't need cpus=1, but still stuck at somewhere after PCI configuration. Tried to remove/add npci=0x2000/0x3000 but nothing changed.

Any ideas for this strange phenomenon?

 

[ExtremeXT]

I tried your latest EFI and SSDT-CPUR.aml, and I was trying to load Monterey installer. But I still need cpus=1 or there will be kernel panic.

After I add cpus=1 in boot-args, I thought it still just stuck at somewhere after PCI configuration. Not sure what happened since there is no SysReport.zip generated in EFI folder in my USB installer.

I also tried to load Big Sur installer, it doesn't need cpus=1, but still stuck at somewhere after PCI configuration. Tried to remove/add npci=0x2000/0x3000 but nothing changed.

Any ideas for this strange phenomenon?
View attachment 7249

Is the image on Monterey with or without cpus=1? Does it still AppleACPIPlatform panic without cpus=1? This seems like an USB/SSD problem rather than an ACPI problem.

If it still panics without cpus=1, send an image of the panic.

- ExtremeXT

 

[Middleman]

I tried your latest EFI and SSDT-CPUR.aml, and I was trying to load Monterey installer. But I still need cpus=1 or there will be kernel panic.

After I add cpus=1 in boot-args, I thought it still just stuck at somewhere after PCI configuration. Not sure what happened since there is no SysReport.zip generated in EFI folder in my USB installer.

I also tried to load Big Sur installer, it doesn't need cpus=1, but still stuck at somewhere after PCI configuration. Tried to remove/add npci=0x2000/0x3000 but nothing changed.

Any ideas for this strange phenomenon?
View attachment 7249

The above image shows it is stalling at something related to your USBToolBox.kext. Did you also enable UTBMap.kext as part of the package? UTBMap should load as secondary kext.

 

[zty199]

Is the image on Monterey with or without cpus=1? Does it still AppleACPIPlatform panic without cpus=1? This seems like an USB/SSD problem rather than an ACPI problem.

If it still panics without cpus=1, send an image of the panic.

- ExtremeXT

That image on Monterey is with cpus=1.

And Here's the image without cpus=1.
* Still can't get SysReport......

 

[zty199]

The above image shows it is stalling at something related to your USBToolBox.kext. Did you also enable UTBMap.kext as part of the package? UTBMap should load as secondary kext.

I think there's nothing wrong with these two kexts in config.plist......


Actually I disabled part of kexts like RealtekRTL8111 and VoodooPS2Trackpad, itlwm, so it seems be to stuck at USBToolBox:....time out. Everytime it stuck shortly after PCI Configuration end.

 

[ExtremeXT]

@zty199 Please try this EFI.

I would also like to know what exact macOS version you're trying to boot (12.4, 12.5 etc).

- ExtremeXT

 

[Middleman]

I think there's nothing wrong with these two kexts in config.plist......
View attachment 7251

Actually I disabled part of kexts like RealtekRTL8111 and VoodooPS2Trackpad, itlwm, so it seems be to stuck at USBToolBox:....time out. Everytime it stuck shortly after PCI Configuration end.

Alright, I already see an issue. Your VirtualSMC is in the wrong place. VirtualSMC is a primary OC kext so must be loaded after Lilu and Whatevergreen and AppleALC.
Then underneath VirtualSMC we load AMDRyzenCPUPowerManagement and SMCAMDProcessor.kext in that order.

If it also helps, this kext list is from OGNerd's working Legion 5 build afaik. You'll notice he added GenericUSBXHCI.kext as well to the build. However he had put UTBMap up top which I don't agree with. It usually must come after VirtualSMC:

 

[ExtremeXT]

Alright, I already see an issue. Your VirtualSMC is in the wrong place. VirtualSMC is a primary OC kext so must be loaded after Lilu and Whatevergreen and AppleALC.
Then underneath VirtualSMC we load AMDRyzenCPUPowerManagement and SMCAMDProcessor.kext in that order.

If it also helps, this kext list is from OGNerd's working Legion 5 build afaik. You'll notice he added GenericUSBXHCI.kext as well to the build. However he had put UTBMap up top which I don't agree with. It usually must come after VirtualSMC:

View attachment 7253

This is wrong. VirtualSMC IS in fact critical to booting, but it doesn't HAVE to be loaded BEFORE the kexts that DON'T require it. The kext list order was done by ProperTree's OC Clean Snapshot function which checks all prerequisites of all the kexts and generates a CORRECT and CLEAN order.

Also, we are now trying to fix the non-monotonic time AppleACPIPlatform, not the issue when using cpus=1.

- ExtremeXT

 

[zty199]

@zty199 Please try this EFI.

I would also like to know what exact macOS version you're trying to boot (12.4, 12.5 etc).

- ExtremeXT

Still got kernel panic... I made this usb installer quite a long time ago, it should be 12.3 beta 1/2......

 

[ExtremeXT]

Still got kernel panic... I made this usb installer quite a long time ago, it should be 12.3 beta 1/2......
View attachment 7254

Please try latest Monterey.

 

[Middleman]

Still got kernel panic... I made this usb installer quite a long time ago, it should be 12.3 beta 1/2......
View attachment 7254

Check if it is missing AppleMCEReporterDisabler.kext. That is essential to booting Monterey 12.4+ on AMD setups.

 

[ExtremeXT]

Check if it is missing AppleMCEReporterDisabler.kext. That is essential to booting Monterey 12.4+ on AMD setups.

The EFI has AppleMCEReporterDisabler, and it wouldn't stop booting at that stage if it was missing anyway.

On another note, I just realized that we fixed "a bit" of the panic! The AppleACPIPlatform part is gone from the backtrace, that leaves us with the "Non-monotomic time" part.
@zty199 Send a screenshot of the panic from latest Monterey 12.6 when you can.

 

[zty199]

The EFI has AppleMCEReporterDisabler, and it wouldn't stop booting at that stage if it was missing anyway.

On another note, I just realized that we fixed "a bit" of the panic! The AppleACPIPlatform part is gone from the backtrace, that leaves us with the "Non-monotomic time" part.
@zty199 Send a screenshot of the panic from latest Monterey 12.6 when you can.

Panic from Monterey 12.6

 

[craighazan]

Panic from Monterey 12.6

Try a different Monterey installer, I had the most success with 12.2, later versions seem to be problematic, for me at least. I know, it takes a long time to create installers, but you look like your almost there, don't give up!.

 

[ExtremeXT]

Panic from Monterey 12.6
View attachment 7258

Thanks. I looked at the sched_prim.c file in the XNU Kernel source code (nice of Apple to let us know exactly where to search) and found that it's related to the TSC (Time Stamp Counter) Syncronization of the CPU cores. The section of the code which gives the panic is: https://github.com/apple-oss-distributions/xnu/blob/xnu-8020.140.41/osfmk/kern/sched_prim.c#L2836
Unfortunately Apple didn't update the XNU Source Code for macOS 12.6 yet, but I still managed to find the place where it calls the panic.
Image 1 is the code of XNU that panics if the time between cores does not match (not syncronized properly).

As seen when comparing the Big Sur and Monterey code (Image 2), Big Sur did not check for the monotonic time at this stage. Big Sur only has one monotonic time check (which passes on the laptop as seen when running Big Sur), but Monterey has two more. The order is: NEW_MONTEREY_1 -> NEW_MONTEREY_2 -> OLD_BIG_SUR, the first one added in Monterey passes just fine on the laptop, but the middle one doesn't. We also shouldn't need to worry about the one that also existed in Big Sur, as it should pass just as fine as it did on Big Sur.

My idea is to revert this part of the code back to the one in Big Sur, but for that I need to generate Kernel Patch values which I never did before and I am unsure on how to do so. Maybe someone like @Shaneee can help?
That said, I will try to send a few more testing EFIs that actually fix the TSC syncronization, but I am not sure if I would be successful. The best solution would be to remove the panic anyways.

- ExtremeXT