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

 

[Edhawk]

Are you still using the MacPro or iMacPro SMBIOS?

 

[OG Nerd]

Are you still using the MacPro or iMacPro SMBIOS?

The iMac Pro, it hangs at boot with the Mac Pro symbios

 

[Edhawk]

Same for a MacBook Pro SMBIOS?

When you changed the SMBIOS, trying these different definitions. Do you remember to edit the USB kext to reflect the changes to the SMBIOS, as the kext using one definition and the config another will cause macOS not to boot, especially from a USB. You would also need to use the NvramReset.efi driver on the OC boot screen.

 

[OG Nerd]

Same for a MacBook Pro SMBIOS?

When you changed the SMBIOS, trying these different definitions. Do you remember to edit the USB kext to reflect the changes to the SMBIOS, as the kext using one definition and the config another will cause macOS not to boot, especially from a USB. You would also need to use the NvramReset.efi driver on the OC boot screen.

I did reset nvram, but was using my usb kext from usb toolbox. I created the usb mapping booting off of windows 11 EFI from its ssd, totally bypassing OPENCORE and Mac OS. I thought that would get the most accurate map possible.

 

[Edhawk]

Which version of OpenCore are you currently using with Big Sur and Monterey?

Can you post a copy of the USB kext, just so I can see what you are using.

 

[OG Nerd]

Which version of OpenCore are you currently using with Big Sur and Monterey?

Can you post a copy of the USB kext, just so I can see what you are using.

OPENCORE 8.2… the laptop is at work so will have to grab kext Monday. It is however in the efi I posted on post #491

 

[Middleman]

I did reset nvram, but was using my usb kext from usb toolbox. I created the usb mapping booting off of windows 11 EFI from its ssd, totally bypassing OPENCORE and Mac OS. I thought that would get the most accurate map possible.

That's strange, because I've managed to get the USB ports on my B550 to work with Monterey 12.4. On mine, all that is required are the XHC rename SSDTs (XHC0-TO-XHC & PTXH-TO-XHC2), EC-USBX-DESKTOP and USBInjectAll with XHCIPortLimit turned off.

 

[OG Nerd]

That's strange, because I've managed to get the USB ports on my B550 to work with Monterey 12.4. On mine, all that is required are the XHC rename SSDTs (XHC0-TO-XHC & PTXH-TO-XHC2), EC-USBX-DESKTOP and USBInjectAll with XHCIPortLimit turned off.

I’m thinking there’s something different or new with this laptop mobo that maybe isn’t supported yet, I dunno.

 

[Jo-Toku]

Laptop and desktops certainly do not work the same as desktop at least for Ryzen. I have 3 Ryzen laptops, 2 with desktop grade CPUs, and the maker Quantas certainly had to modify things for mobile. Therefore more tweaking may be required for laptops that desktops to get them to work properly. The other issue is that the makers of openores do not have any experience on Ryzen mobile since everyone tend to just use the Intel UHD630.

 

[Jo-Toku]

At this rate, I may just wait and get the Zbook with the new 12900HX which is the desktop Alder Lake and crammed down to 55 watts. Benchmarks show to perform just like the desktop. The new Fury G9 (Not released yet) will still have the Radeon pro 6600m as option.

Is possible I may have to sell the Legion 5 since I dont see fix anytime soon

 

[zxc2689963]

There are two critical issues with Legion 5 that have yet to be solved and will probably never be solved. It takes a very professional person to understand the problem, Significant changes to DSDT or BIOS may be required.

1. When BigSur is installed, it will be randomly stuck in IONVME and apfs_module_start , and you need to forcibly reboot several times to boot successfully. I tested and found that it is not nvMe hard disk problem, because I tried to remove the hard disk, it is also stuck here, and it has nothing to do with USB mapping, as long as it can be successfully guided, all the USB will be valid.This situation is the same as no EC,Has been put in the correct SSDT-EC

2. Installing Monterey using a full-core CPU will panic the kernel, and there is still no clue


I did everything I could and failed in the end, which is by no means a simple thing.I've given up. WINDOWS is good, too.

 

[Jo-Toku]

There are two critical issues with Legion 5 that have yet to be solved and will probably never be solved. It takes a very professional person to understand the problem, Significant changes to DSDT or BIOS may be required.

1. When BigSur is installed, it will be randomly stuck in IONVME and apfs_module_start , and you need to forcibly reboot several times to boot successfully. I tested and found that it is not nvMe hard disk problem, because I tried to remove the hard disk, it is also stuck here, and it has nothing to do with USB mapping, as long as it can be successfully guided, all the USB will be valid.This situation is the same as no EC,Has been put in the correct SSDT-EC

2. Installing Monterey using a full-core CPU will panic the kernel, and there is still no clue


I did everything I could and failed in the end, which is by no means a simple thing.I've given up. WINDOWS is good, too.

I think Lenovo somehow fucked up with the Bios. The Asus G14 don't seem to suffer as much. Too bad I am not interested on 14 inch laptops, they are too small for my needs. Seems the Zbook is the best options of the big players with a Radeon 6600m, and tons of upgrade ability. The G8 tops out with the 11900hk and is just a little faster than the Ryzen 5800h, but the new 12900HX will simply destroy that chip. The new G9 top size is 16 inch at 16:10 aspect ratio. I will miss the 17 inch display though

 

[Edhawk]

As this laptop has an EC already set in the DSDT.aml, it doesn't need a new one. When using Corpnewt's SSDTTime terminal command/script you should be using option 3 not option 2. As option 3 creates a FAKE EC entry that leaves the existing \_SB.PCI0.LPC0.EC0 entries in the DSDT.aml undisturbed.

List of options available in SSDTTime.



This is what the SSDT-EC.aml created using option 3 looks like when opened in MaciASL.
This is what SSDTTime displays when creating the SSDT-EC.aml

Of the other SSDT's that can be generated by Corpnewt's SSDTTim script most are not of use with an AMD system, whether a laptop or Desktop.

The following screenshots show the display from SSDTTime when options 1, 4, 5, 6 & 7 are selected.

Option 1 HPET

An SSDT-HPET.aml is generated that deals with the most common IRQ clashes for IRQ 2, 8 & 11.

Option 4 PLUG

No SSDT-PLUG is generated. Not sure why but a guess would be it is looking for an Intel setting and not finding it.

Option 5 PMC

An SSDT-PMC.aml is generated but I don't think the Legion 5 laptop needs it for NVRAM to work.

Option 6 AWAC

No SSDT-AWAC.aml is generated, as the script can't find the first thread of the CPU, again because it is looking for an intel setting.

Option 7 USB-Reset

An SSDT-USB-Reset.aml is generated. This SSDT would be of use when discovering the USB ports.

 

[Edhawk]

Attached is a copy of the 'Results' folder generated by SSDTTime, along with the DSDT.aml used from the Legion 5 laptop.

SSDT9.aml contains the details for the CPU threads, as shown below.

C000 being the detail that SSDTTime couldn't locate to create an SSDT-PLUG.aml.

SSDT-CPUR-5800HX.aml has been created to deal with this issue for the Legion 5 laptop.

An issue I discovered when looking through the SSDT's for the Legion 5 laptop is that SSDT11.aml and SSDT12.aml are identical tables. Which probably creates some sort of error when the system is booting, as you don't want or need two tables undertaking the same task.



Dropping SSDT12.aml would to me seem logical, so the duplicate table is not used. Similar to how Intel Ivy Bridge systems have to drop the CPU power management tables in order to boot macOS. The details for SSDT12.aml would need to be added to an entry in the ACPI > Delete section of the config.plist.

SSDT16.aml contains a second EmbeddedControl device (EC0) which appears to be dealing with Sleep/wake calls. It uses the same \_SB.PCI0.LPC0.EC0 ACPI path, but is set to work via a different OperationRegion - ECSI. When the OperationRegion for the EC device in the DSDT.aml is set to work via - ERAM.

I have hacked a number of Intel laptops, so finding two Embedded Control devices, one in the DSDT and another in an SSDT is not normal.

 

[Edhawk]

The DSDT and IOReg for the Legion 5 laptop don't marry up, well not the ones I obtained from posts in this thread or from communications with @OG Nerd

The SSDT-CPUR-5800XH.aml is setting the CPU as one thing, C000, C001, C002 etc. which marries up in part to the SSDT9.aml, but not with the entries in the DSDT.aml.

The IOReg is showing Big Sur is enabling the CPU using PR00, PR01, PR02 etc. As shown in the screenshot below from OG Nerd's IOReg.

Excerpt from IOReg showing connection to CPU using AMDRyzenCPUPowerManagement.kext on 1st CPU thread, on PR00 instead of C000.

C000, C001 etc. are present in the IOReg but devoid of any meaningful attributes.

The fact the 8-cores/16-threads are being activated in Big Sur may be related to the attributes attaching to PR00.

Maybe the fixes used for Monterey are moving these processes from PR00 to C000 and they simply aren't working as expected with C000.

In the past when Hacking HDET (X79, X99 and X299) systems it was necessary to rename the CPU threads so macOS would recognise the CPU correctly. While this was required with CLOVER used as the boot loader I don't know if the same would be necessary when using OpenCore. I know the OC guide frowns on what they call 'Cosmetic' fixes but maybe using a rename patch for each of the 16 threads to be correctly named as PR00, PR01 etc. might help.

The rename patches would look something like this:

Example ACPI Rename patches for C000 to PR00 and C001 toPR01.

The rename patches would work on both the DSDT.aml and SSDT9.aml or any other system SSDT that contained the C000 naming.

SSDT-CPUR-5800XH.aml would then need to be set to use PR00 etc. so everything is working on the same page.

 

[Edhawk]

There are 2 x NVME connectors in the Legion 5 laptop. These are shown below in the two screenshots.

/_SB/PCI0/GPP1/DEV0

/_SB/PCI0/GPP6

This second controller is probably the device that is causing issues with the NVME and boot errors.

The ACPI path for this device is not complete. The ACPI path for this second controller is \_SB.PCI0.GPP6 with the last part missing or not correctly named. It should be a four-letter name used to define the controller, instead it is using pci1cc1,5236.

Possibly renaming this device from pci1cc1,5236 to DEV1 or something similar might help fix this issue. The patch would look something like this in ProperTree.

Rename patch for second NVME controller.

Hope the posts above are helpful.

 

[OG Nerd]

There are 2 x NVME connectors in the Legion 5 laptop. These are shown below in the two screenshots.

View attachment 6652 /_SB/PCI0/GPP1/DEV0

View attachment 6653 /_SB/PCI0/GPP6

This second controller is probably the device that is causing issues with the NVME and boot errors.

The ACPI path for this device is not complete. The ACPI path for this second controller is \_SB.PCI0.GPP6 with the last part missing or not correctly named. It should be a four-letter name used to define the controller, instead it is using pci1cc1,5236.

Possibly renaming this device from pci1cc1,5236 to DEV1 or something similar might help fix this issue. The patch would look something like this in ProperTree.

View attachment 6654 Rename patch for second NVME controller.

Hope the posts above are helpful.

I seem to have figured the nvme issue in Big Sur that zxc2689963 mentioned by adding the device properties and "built-in=01" in the config.plist. (don't know if it is just dumb luck or maybe the combination of SSD's Im using, I am using XPG Gammix 1TB in each nvme slot. It boots into Big Sur Consistently with my latest EFI. As for the rename CPU patches for Monterey, do you think doing the renames on Big Sur would produce the same results or do I need to upgrade to Monterey and work from there with the rename of CPU cores?

Next question, I am a little confused about the renaming of the CPU patches, if I were to post the current big sur EFI, would you be willing to change the patches so I do not screw it up? Most of this is starting to get above my level, I am willing to learn, just am really confused at the moment lol. Here is my last booted EFI for Big Sur that seems to not have the ionvme issue anymore.

 

[Edhawk]

OK, here is a revised EFI for you to try.

1. I have added the 16 patches for the CPU rename.
2. I have removed the SSDT-CPUR-5800XH.aml table and replaced it with SSDT-CPUR-PR.aml, as the SSDt you were using wouldn't have worked with the new CPU names.
3. I made the necessary changes in the config.plist to reflect the use of the new SSDT.
4. Removed a number of placeholder entries as they don't work on an AMD system.

See if this EFI makes any difference when booting Big Sur.

• You will need to create a copy of your IOReg before making the EFI change.
• Clear Nvram when initially booting from the revised EFI.
• Once booted in to Big Sur, create a new copy of your IOReg.
• Post both IOReg copies here, so I can see what if any difference the revised EFI made.

 

[OG Nerd]

OK, here is a revised EFI for you to try.

1. I have added the 16 patches for the CPU rename.
2. I have removed the SSDT-CPUR-5800XH.aml table and replaced it with SSDT-CPUR-PR.aml, as the SSDt you were using wouldn't have worked with the new CPU names.
3. I made the necessary changes in the config.plist to reflect the use of the new SSDT.
4. Removed a number of placeholder entries as they don't work on an AMD system.

See if this EFI makes any difference when booting Big Sur.

• You will need to create a copy of your IOReg before making the EFI change.
• Clear Nvram when initially booting from the revised EFI.
• Once booted in to Big Sur, create a new copy of your IOReg.
• Post both IOReg copies here, so I can see what if any difference the revised EFI made.

Ok, I will try it tomorrow and report back to you. Thank you.

 

[OG Nerd]

OK, here is a revised EFI for you to try.

1. I have added the 16 patches for the CPU rename.
2. I have removed the SSDT-CPUR-5800XH.aml table and replaced it with SSDT-CPUR-PR.aml, as the SSDt you were using wouldn't have worked with the new CPU names.
3. I made the necessary changes in the config.plist to reflect the use of the new SSDT.
4. Removed a number of placeholder entries as they don't work on an AMD system.

See if this EFI makes any difference when booting Big Sur.

• You will need to create a copy of your IOReg before making the EFI change.
• Clear Nvram when initially booting from the revised EFI.
• Once booted in to Big Sur, create a new copy of your IOReg.
• Post both IOReg copies here, so I can see what if any difference the revised EFI made.

OK, it booted up with your EFI, something I noticed, it booted about about 2-3 seconds faster with your last posted EFI, so hopefully we are going in the right direction. Here are the IOReg dumps BEFORE and AFTER your EFI.