• Become a Premium Member for $25/year with no ads to improve your community experience. Upgrade to Pro Account for faster response and no wait times!

MacOS Sequoia 15.7.5 killed Continuity on my Hackintosh

Here are the updated PR files you requested (current config.plist and fresh IOReg) after applying your previous checklist. Both validate correctly with ocvalidate.

I have also extracted a DMAR.aml under Windows using SSDTTime with VT-d enabled in BIOS, but I have not modified or added it to OpenCore yet. I will wait for your instructions on how exactly to patch and use it.
 

Attachments

Last edited:
Here are the updated PR files you requested (current config.plist and fresh IOReg) after applying your previous checklist. Both validate correctly with ocvalidate.

I have also extracted a DMAR.aml under Windows using SSDTTime with VT-d enabled in BIOS, but I have not modified or added it to OpenCore yet. I will wait for your instructions on how exactly to patch and use it.
Still a couple of issues. Make the following changes:

- Enable ExtendBTFeatureFlags and Remove ProvideCurrentCpuInfo
- Kexts loading order is not correct.
- You were asked to remove the Kernel patches as you're already using a supported SMBIOS.
- agdpmod=pikera shouldn't be required for your hardware.
- RestrictEvent patching is not done correctly.
- Drivers loading order is not correct. Mandatory drivers should load first.
- Follow the VT-d implementation guide. Just a quick tip - Your DMAR table has two memory reserved region. Patch it and you should be good to go!
 
Still a couple of issues. Make the following changes:

- Enable ExtendBTFeatureFlags and Remove ProvideCurrentCpuInfo
- Kexts loading order is not correct.
- You were asked to remove the Kernel patches as you're already using a supported SMBIOS.
- agdpmod=pikera shouldn't be required for your hardware.
- RestrictEvent patching is not done correctly.
- Drivers loading order is not correct. Mandatory drivers should load first.
- Follow the VT-d implementation guide. Just a quick tip - Your DMAR table has two memory reserved region. Patch it and you should be good to go!
I have a question about my DMAR table. In the hex/decoded view I see two reserved memory regions:
– Base 0x00000000B182C000 – End 0x00000000B184BFFF – PCI Path 14,00
– Base 0x00000000B3800000 – End 0x00000000B7FFFFFF – PCI Path 02,00
You mentioned that my DMAR table has just one memory reserved region to patch. Which one exactly should I remove and which one should I keep?
Also, when I try to compile the edited DMAR.dsl with iasl 20251212 on two different Macs, iasl hangs and never finishes. Could you please compile the corrected DMAR.dsl into SSDT-DMAR.aml for AppleVTD for me?
 
I have a question about my DMAR table. In the hex/decoded view I see two reserved memory regions:
– Base 0x00000000B182C000 – End 0x00000000B184BFFF – PCI Path 14,00
– Base 0x00000000B3800000 – End 0x00000000B7FFFFFF – PCI Path 02,00
You mentioned that my DMAR table has just one memory reserved region to patch. Which one exactly should I remove and which one should I keep?
Also, when I try to compile the edited DMAR.dsl with iasl 20251212 on two different Macs, iasl hangs and never finishes. Could you please compile the corrected DMAR.dsl into SSDT-DMAR.aml for AppleVTD for me?
Delete line 70-101 in the original DMAR table and then compile. Should get compiled. You still have to drop the OEM DMAR table and then inject the patched one.
 
Delete line 70-101 in the original DMAR table and then compile. Should get compiled. You still have to drop the OEM DMAR table and then inject the patched one.
I really appreciate all your help. I was not able to fully implement your advices as a whole, despite spending a few days trying. The key problem was applying the custom ACPI file generated under Windows using SSDTTime to dump the AML tables, Intel ACPI compiler iasl to decompile and compile AML/DSL, and Notepad++ for editing. No matter how many combinations I tried, either the USB disks and keyboard would stop working, or the keyboard worked but the USB disks did not. Enabling VT-d in BIOS only made things worse instead of helping. Even though I followed your guide very carefully, I still could not get the CPU to report correctly without errors. The values I had set in config.plist under PlatformInfo/Generic kept getting lost, and instead I would see data for some random MacBook, and even that was mostly empty, which in turn broke my software licensing for development tools.

However, I have still incorporated many of your suggested fixes into my config.plist. I also set the iGPU to headless mode as you recommended, and I consider that a small but meaningful success. I am not discarding our experiment; I only saved the new config.plist files under backup names and went back to my older one, with those corrections from you that did not destabilize the system. I may well return to this project later. For now, thank you for your time and assistance. I truly appreciate it, and it was definitely not time wasted, quite the opposite. Warmest greetings from Poland.

P.S. I've been using Hackintosh since right after the OS X Leopard release. I plan to stick with this one—probably my last—until it falls apart. I'm an optimist; I just transferred data from four 20-year-old HDDs to a new 2TB HDD. Adventure, keep going!
 
Last edited:

Trending content

Forum statistics

Threads
2,219
Messages
20,419
Members
30,951
Latest member
Dartkill