acpi error
- Thread starter mumin16
- Start date
-
Hello Guest. Before you post check the Troubleshooting guide here, Dortania Troubleshooting
At least one of the errors shown (blurred) in the image above is related to your SSDT-i225V.aml table. In that it can't find the device at the ACPI address used in the SSDT.
Remove the SSDT-i225V.aml table from /EFI/OC/ACPI folder and disable or remove the companion ACPI > patch from the config.plist. See if that solves the issues you are seeing.
You have 2 x USB configuration kexts in your setup. This is likely to be part of the other issue we are not seeing clearly, as it is related to the XH00 device (USB).
You have a USBMap.kext and a UTBMap.kext in your setup, you shouldn't be using both at the same time. Use one or the other, as long as the one you use is set correctly.
Your USBMap.kext is complete and utter rubbish. The kext is trying to activate 26 x ports on 4 x USB controllers XH00, XHC0, XHC1 & XHC2. This gives a total of 104 x USB ports! No motherboard has anywhere near that number of USB ports. I would recommend deleting this kext from your setup, as it is complete nonsense and never going to work.
Your UTBMap.kext looks to at least activate the same 4 x USB controllers, with XHOO activating 17 x ports, XHC0 activating 4 x ports, XHC1 activating 4 x ports and XHC2 activating 1 x port. Giving a total of 26 x USB ports. The XH00 controller is trying to activate 2 x ports too many, each controller is limited to 15 x ports. So you need to disable/remove 2 x ports from this controller of the kext to be more accurate about what it is activating.
The other issue you have with this kext is that the UsbConnector types for a large number of the ports are set incorrectly. I say this with confidence, as you have 11 x ports set as 'Internal', using the (255) USB connector type. When your motherboard only has 2 x USB2 headers that would provide a maximum of 4 x 'Internal' ports. You will also have a USB2 port attached to the WiFi M.2 connector, serving the Intel Bluetooth module, which should also be set as 'Internal' with connector type (255). These will all be HSxx ports, none of the SSxx ports should ever be set as 'Internal' (255).
XH00 > 4 of 8 x ports are likely to be served from USB3 header ports, i.e. USB2 virtual ports, which should be set as USB3 connector type to match the physical side of the port/header.
XH00 > 4 of 8 x Port are correctly set as 'Internal' with connector type (255).
XHC0 > HS01 and SS01 are likely to be USB3 ports.
XHC2 > HS01 is likely to be your M.2 Bluetooth connector.
I assume you have set the USB3 motherboard headers as 'Internal' with the (255) connector. These USB3 header ports should always be set as USB3 (3) connector type. I would recommend you go through your UTBMap.kext/Contents/Info.plist and edit the USB3 header ports to accurately reflect they are USB3 ports or companion USB2 virtual ports served from a USB3 header.
So the UTBMap.kext will also cause issues if left unedited, most likely sleep/wake/reboot/no boot issues when you try to use the system with macOS.
Remove the SSDT-i225V.aml table from /EFI/OC/ACPI folder and disable or remove the companion ACPI > patch from the config.plist. See if that solves the issues you are seeing.
You have 2 x USB configuration kexts in your setup. This is likely to be part of the other issue we are not seeing clearly, as it is related to the XH00 device (USB).
You have a USBMap.kext and a UTBMap.kext in your setup, you shouldn't be using both at the same time. Use one or the other, as long as the one you use is set correctly.
Your USBMap.kext is complete and utter rubbish. The kext is trying to activate 26 x ports on 4 x USB controllers XH00, XHC0, XHC1 & XHC2. This gives a total of 104 x USB ports! No motherboard has anywhere near that number of USB ports. I would recommend deleting this kext from your setup, as it is complete nonsense and never going to work.
Your UTBMap.kext looks to at least activate the same 4 x USB controllers, with XHOO activating 17 x ports, XHC0 activating 4 x ports, XHC1 activating 4 x ports and XHC2 activating 1 x port. Giving a total of 26 x USB ports. The XH00 controller is trying to activate 2 x ports too many, each controller is limited to 15 x ports. So you need to disable/remove 2 x ports from this controller of the kext to be more accurate about what it is activating.
The other issue you have with this kext is that the UsbConnector types for a large number of the ports are set incorrectly. I say this with confidence, as you have 11 x ports set as 'Internal', using the (255) USB connector type. When your motherboard only has 2 x USB2 headers that would provide a maximum of 4 x 'Internal' ports. You will also have a USB2 port attached to the WiFi M.2 connector, serving the Intel Bluetooth module, which should also be set as 'Internal' with connector type (255). These will all be HSxx ports, none of the SSxx ports should ever be set as 'Internal' (255).
XH00 > 4 of 8 x ports are likely to be served from USB3 header ports, i.e. USB2 virtual ports, which should be set as USB3 connector type to match the physical side of the port/header.
XH00 > 4 of 8 x Port are correctly set as 'Internal' with connector type (255).
XHC0 > HS01 and SS01 are likely to be USB3 ports.
XHC2 > HS01 is likely to be your M.2 Bluetooth connector.
I assume you have set the USB3 motherboard headers as 'Internal' with the (255) connector. These USB3 header ports should always be set as USB3 (3) connector type. I would recommend you go through your UTBMap.kext/Contents/Info.plist and edit the USB3 header ports to accurately reflect they are USB3 ports or companion USB2 virtual ports served from a USB3 header.
So the UTBMap.kext will also cause issues if left unedited, most likely sleep/wake/reboot/no boot issues when you try to use the system with macOS.
You are using an MSI motherboard, so why are you using Gigabyte specific ACPI patches? Does your motherboard really need these two patches?
You have Audio codec layout ID > Number > 1 in device properties section of the config.plist, and as alcid=11 in NVRAM > boot args section. Which is correct? Boot arg will over ride the device properties entry, so it is not used.
You do not need to use -lilubetaall boot argument, the latest version of OC and Lilu.kext work with Ventura without the need for this boot argument.
Why have you disabled SIP (csr-active-config) in your OC setup? That isn't a requirement for running macOS on a Ryzen system.
You have Audio codec layout ID > Number > 1 in device properties section of the config.plist, and as alcid=11 in NVRAM > boot args section. Which is correct? Boot arg will over ride the device properties entry, so it is not used.
You do not need to use -lilubetaall boot argument, the latest version of OC and Lilu.kext work with Ventura without the need for this boot argument.
Why have you disabled SIP (csr-active-config) in your OC setup? That isn't a requirement for running macOS on a Ryzen system.
Because i am a beginner, I couldn't create/find/modify efi for my mainboard and then I tried the efi's I found here. for sound(Portable Speaker), alcid=11 is work. for vitualbox(genymotion-anroid emulator), i used csr-active-config. QEMU not work.
As a Beginner you are expected to do some research, i.e. read the Dortania Ryzen OpenCore Guides as a minimum. Those guides clearly explain how to create and edit an AMD EFI, which tools/Apps you need even for working in Windows and/or a Linux OS while creating the EFI. So being a beginner is not an acceptable excuse. Everyone was a beginner at some point in time and had to spend time learning to install macOS on Non-Apple components.
Using someone else's EFI, without understanding what it is doing is simply lazy.
You do understand that the whole point of the AMS OS X website is for users to run macOS in its Vanilla state, on AMD systems, Yes? Virtualising macOS isn't a Vanilla install.
Using someone else's EFI, without understanding what it is doing is simply lazy.
You do understand that the whole point of the AMS OS X website is for users to run macOS in its Vanilla state, on AMD systems, Yes? Virtualising macOS isn't a Vanilla install.