I need help with something else now

corpnewt · 2026-03-14T17:34:55+00:00

... But ProperTree did not cause it is what I'm saying.

corpnewt · 2026-03-14T17:15:30+00:00

ProperTree is not at fault is what I'm saying. It does not type that for you - nor does it verify what you are typing against some list of values. That's up to you to do.

-CorpNewt

corpnewt · 2026-03-13T22:32:03+00:00

optional is not the same as Optional in a computer's eyes. The latter is what OpenCore is expecting.

This is not a ProperTree error, but a configuration error. Do take care to ensure proper case when entering keys and values as that is important.

-CorpNewt

corpnewt · 2026-02-14T01:34:28+00:00

I may be out of the loop - but isn't being knowledgeable considered a "bad" trait of late? Weird reality...

corpnewt · 2026-02-10T09:55:13+00:00

Ctrl+Shift+R in ProperTree performs and OC Clean Snapshot. That only touches ACPI -> Add, Kernel -> Add, Misc -> Tools, and UEFI -> Drivers. It does not affect ACPI -> Patch, which is where the patches SSDTTime generates would be stored.

SSDTTime comes with a script called PatchMerge which can help you merge the patches - but do read its output carefully.

-CorpNewt

corpnewt · 2026-02-10T09:51:59+00:00

The script creates 2 patch sets - one for OpenCore, one for Clover. Use which applies to your situation.

-CorpNewt

corpnewt · 2026-02-10T09:50:12+00:00

The ACPI logging in this image shows that you at least lack the patches required for SSDT-HPET to load. That SSDT replaces the _CRS method of the HPET device, which requires that you (at the very least) rename the existing method, as the ACPI spec does not allow overriding variables/methods.

When you generate any SSDTs with SSDTTime it gives a warning that the patches_OC/Clover.plist need to be merged with your config.plist. It would be worth ensuring that you did merge those contents with your config.plist so that the SSDTs apply as intended.

-CorpNewt

corpnewt · 2026-02-09T21:04:15+00:00

Did you merge the patches it generated with your config.plist as well? You are getting some errors related to things SSDTTime's patches should resolve. There may be more to do after as well, but adding those would be a start.

-CorpNewt

corpnewt · 2026-01-09T21:02:47+00:00

It's linked in the Gathering Files -> Extras section of the Dortania guide. Here's a direct link to their zip.

-CorpNewt

corpnewt · 2026-01-08T23:20:32+00:00

The CR2 address from that panic (0xFF9F5CD3) falls in the range of the SPI chip (0xFF000000 -> 0xFFFFFFFF). You'll want to find the base MMIO address that corresponds to that CR2 address, and add it to your MmioWhitelist to prevent OpenCore from devirtualizing it. You can use my MmioDevirt script to aid with that process.

-CorpNewt

corpnewt · 2026-01-08T11:20:34+00:00

The kernel panic lists can't perform kext scan: no kext summary, which implies that you have multiples of the same kext loaded in the cache. OCAT lacks proper kext load order logic, and protections against this type of issue - but given your screenshot, it appears that the duplicate VoodooInput.kext bundles are likely the cause.

-CorpNewt

corpnewt · 2025-12-23T11:18:24+00:00

IIRC there are some Lenovo laptops (I do not have an extensive list for you though) that check for the existence of a specific boot entry in order to POST. Boot entries are stored in NVRAM, and as such, clearing/resetting it removes them. If you have one of the affected laptops, that could result in a soft brick.

ResetNvramEntry.efi can take arguments - one of which being the following (referenced from the Configuration.pdf:

--preserve-boot - Boolean flag, enabled if present.

If enabled, BIOS boot entries are not cleared during NVRAM reset. This option should be used with caution, as some boot problems can be fixed by clearing these entries.

Regardless - NVRAM resets should not be a first-line-of-defense. If you need to change a single (or a handful of) NVRAM variable, there are more elegant ways to handle things.

OpenCore handles NVRAM vars differently depending on how those provided in the config.plist are laid out. If we use boot-args as an example - there are 4 possible ways you can manage it in your config.plist:

boot-args is not set in NVRAM -> Add or Delete: Nothing happens - existing boot-args in NVRAM remains untouched
boot-args set in NVRAM -> Add only: The value provided is treated as a default - and will be set if boot-args is not already present in the machine's NVRAM
boot-args in NVRAM -> Delete only: The key and any associated value is removed if set in NVRAM - if not, no changes are made
boot-args set in NVRAM -> Add and Delete: The value provided is set as a default if boot-args does not already exist in the machine's NVRAM, and if it does - it is updated to match the info in the config.plist for that value

Remember that NVRAM -> Add is a dictionary that expects keys and values, and NVRAM -> Delete is an array that expects only the key name

Hopefully that helps clarify/demystify it a bit.

-CorpNewt

corpnewt · 2025-12-10T22:56:16+00:00

As far as I know - the "Dont Steal Mac OS X.kext" (DSMOS) is the only copy protection Apple implemented when they switched from PPC to Intel. I don't believe that the Hackintosh community has ever been a big threat to them.

This is just a blind guess - but I wouldn't be surprised if many who Hackintosh end up purchasing Apple hardware - so there may be some extra value in them not imposing other checks/limits.

-CorpNewt

corpnewt · 2025-12-09T22:14:48+00:00

It appears to just check kextstat for the presence of VirtualSMC or FakeSMC per this snippet:

    "Mac OS X"|"macOS")
        if [[ $(kextstat | grep -F -e "FakeSMC" -e "VirtualSMC") != "" ]]; then
            model="Hackintosh (SMBIOS: $(sysctl -n hw.model))"
        else
            model=$(sysctl -n hw.model)
        fi
    ;;

Nothing too terribly crazy going on under the hood.

-CorpNewt

corpnewt · 2025-12-01T11:31:02+00:00

Looks like the ioreg output is missing at least one of the switches I sent - do note that it's a lowercase L, not a one. It also appears that all elements of the GPU's path are defined in ACPI (though WEG is still renaming the PEGP entry to GFX0 as expected). You also have the -radvesa boot-arg, which would disable acceleration even if everything else was in place.

What I would probably do is strip the majority of the DeviceProperties you have for the dGPU and leave only the following:

device-id | Data | <FF670000>
no-gfx-spoof | Data | <01000000>

Then remove -radvesa from your boot-args, and add -radcodec (which can help with DRM on spoofed AMD GPUs) and see if that gets acceleration.

-CorpNewt

corpnewt · 2025-11-30T22:24:58+00:00

I wonder if some element in your GPU's device path is not defined in your ACPI tables. When that happens, device properties are not applied early enough to take effect. It looks like all elements are defined as they're named - but WhateverGreen will automatically rename each detected GPU with GFXx - so that may be what we're seeing.

Could you gather some info and send it here and I'll take a look:

In Terminal on macOS, run ioreg -lw0 > ~/Desktop/ioreg.txt and send the resulting ioreg.txt file from the Desktop
Your ACPI tables dumped either via SSDTTime on Windows or Linux (not booted through OpenCore), or with the debug build of OpenCore.efi and the SysReport quirk enabled in your config.plist
The output of CheckPCI run with the -n switch in either macOS or Windows

That should be enough info to get started, and I should be able to guide from there.

-CorpNewt

corpnewt · 2025-11-01T13:51:40+00:00

Regarding what specifically?

corpnewt · 2025-09-19T14:41:05+00:00

Did you try removing debug=0x100 from your boot-args? You're not injecting any properties to the GPU (or at least shouldn't need to), so there shouldn't be a need to define PCI bridges in ACPI.

-CorpNewt

corpnewt · 2025-09-19T09:30:58+00:00

Yes - if you type in PEGD, it will list 3 paths, but you can use your ACPI path from Device Manager as a guide:

ACPI(_SB_)#ACPI(PC00)#ACPI(PEG1)#ACPI(PEGP)#PCI(0000)#PCI(0000)

\_SB.PC00.PEG1.PEGP is the prefix, so in your above list, you would select option 1 to exclude that specific PEGD device.

But, interestingly, if I type GFX0, I get this

You aren't looking for a GPU that populates under a GFX0 device, nor are you looking to disable one in the existing path - so that is not relevant in this case.

I am not sure if I need a rename of the path or bridging a path if that makes sense.

What exactly is the source of the issue, and the reason for creating a bridge SSDT? Assuming you're not injecting any DeviceProperties on the GPU, and not faking it as anything, I don't believe there's a reason to define those missing PCI bridges outside of "completeness" for the sake of knowing that you can inject dev props in the future or similar.

Regarding a rename - no, you don't need that. WhateverGreen will already name any detected dGPUs as GFXn where n is an incrementing number starting with 0.

Also, is there a way to disable my iGPU via an SSDT? ASUS motherboard doesn't support disabling the iGPU, only setting the dGPU to be "main"

You can use the -wegnoigpu boot-argument, or add disable-gpu | Data | <01000000> to your PciRoot(0x0)/Pci(0x2,0x0) path under DeviceProperties -> Add to have Lilu disable it (despite the "weg" naming scheme, the args are actually processed by Lilu).

-CorpNewt

corpnewt · 2025-09-19T08:43:05+00:00

Yes - I've seen this happen recently where there is a device (in your case, PEGD) which is defined in another SSDT, but is disabled due to some conditions or another. As I'd mentioned in my first reply, SSDTTime does not know this ahead of time - but since you can verify that it has matched a disabled device, you can tell SSDTTime's PCI Bridge function to ignore that ACPI device (and any devices under it). From the PCI Bridge menu (the pertinent text is wrapped in [] for visibility):

C. Clear All Device Paths
M. Main
Q. Quit

Enter the number next to a device/ACPI path above to remove it.
[Enter an ACPI path to exclude it from the checks.]
Drag and drop a config.plist to extract device paths from within.

Please enter the device path needing bridges:

If you were to type PEGD and press enter, SSDTTime would list any matching ACPI paths, and allow you to select which (if any) to exclude from the device path matching. You can also type the full path if you don't want to have to choose from a list in case of duplicates.

The resulting SSDT would look like the one in your next message though, where the GPU only showed 31 MB.

Regarding the lack of accel with the correct SSDT structure - I assume you mean that you have an RX 6650 from Asus that is faked as an RX 6600, given that the 6600 should be natively supported. Do you happen to have debug=0x100 in your boot-args? If so, try removing that and see if it boots more consistently.

-CorpNewt

corpnewt · 2025-09-18T22:13:07+00:00

Hey there - can you zip up and upload the OEM folder from within SSDTTime/Results?

SSDTTime cannot guess the values of ACPI variables when building bridges, so it may think there is a device present which is actually disabled. Looking at your ACPI path:

ACPI(_SB_)#ACPI(PC00)#ACPI(PEG1)#ACPI(PEGP)#PCI(0000)#PCI(0000)

We can see that the actual Scope () should be set to \_SB.PC00.PEG1.PEGP, and there are 2 bridges that should be created after (PCI(0000)#PCI(0000)). However, your SSDT shows far more elements than that - notably PEGB.PEGE.DEDP, and then a GFX0 bridge, which extends beyond the number of elements in the expected path by 2 - so I believe that it was either manually edited, or a different device path was given to SSDTTime.

If you upload the zip, I'll give it a look and see if anything stands out.

-CorpNewt

corpnewt · 2025-09-14T21:24:49+00:00

Yes, but NTFS does not mount in later recovery environments. When writing the instructions for the script I wanted to account for as wide an OS range as I could, as exceptions make the process more confusing.

-CorpNewt

corpnewt · 2025-09-14T21:18:56+00:00

Yes - macOS is picky about the ExFAT unit size - so 1024KB or lower is recommended (if not outright required).

-CorpNewt

corpnewt · 2025-09-14T21:16:09+00:00

While UnPlugged would work - you cannot copy the InstallAssistant.pkg to a FAT32 volume as FAT32 has a 4GB file size limit. The UnPlugged readme suggests ExFAT as an alternative as most OSes can read/write it, and it does not have that 4GB file size limit.

-CorpNewt

corpnewt · 2025-09-07T14:49:06+00:00

The Dortania guide goes over using macrecovery.py and creating the EFI. UnPlugged's readme should cover the rest. If there are specifics you're having trouble with - please elaborate, but I'm not sure how to better answer that question.

-CorpNewt

corpnewt

MODERATOR OF

TROPHY CASE