[SUCCESS] Gigabyte Designare Z390 (Thunderbolt 3) + i7-9700K + AMD RX 580

I just updated to 13.3 - I have 32GB RAM but didn't need to apply the patch, ethernet and WiFi working as before...

Does anyone have iCloud private relay working?
Is AppleVTD enabled?
Outstanding work! May I ask what these five bytes were doing?
Ah, do I foresee a Patch Theory post? The solution turned out to be simpler than anticipated, but I’ll provide a description shortly.
** Patch Theory **
WiFi and Ethernet in macOS 13.3 with AppleVTD

As requested by some, this post explains how the patch was found and what the patch does.

Sometimes it is helpful to participate in the Apple public beta program. When the first 13.3 public beta was released we found some issues related to CPU topology that affected (a) Intel processors with P-cores and E-cores, and (b) all AMD processors. But WiFi and Ethernet worked properly.

In the last two 13.3 public betas, however, WiFi and Ethernet were adversely impacted. The problem was limited to kexts (not to dexts) when AppleVTD was enabled and the system had more than 16GB memory.

Discovery Stage 1:
Not knowing where the problem lay, it was first necessary to isolate the root cause. The first question was, is the problem in one of the kernel extensions or is it deeper within the kernel itself or some other part of the OS? To answer this, the following was done:
  • Late beta of 13.3 was installed on a spare SSD
  • All files in /System/Library/Extensions were replaced by those from an early 13.3 beta build
  • A Frankenstein hybrid was thereby created and it booted and worked perfectly
Discovery Stage 2:
The next question was, which kext or kexts is the culprit? There are hundreds of kexts, but only a handful are responsible for WiFi and Ethernet. The steps of Discovery Stage 1 were repeated, but instead of replacing all kexts, one or two were replaced at a time:
  • Replaced IONetworkingFamily.kext
  • Result: No good -- WiFi and Ethernet still down
  • Replaced IO80211FamilyLegacy.kext that governs Broadcom WiFi
  • Result: No good -- WiFi still down
  • Replaced all 5 Broadcom firmware kexts
  • Result: No good -- WiFi still down
  • Realizing that WiFi and Ethernet are down, there must be a common higher-level kext that affects them both. Because the problem occurs only when AppleVTD is enabled, and because AppleVTD is managed by IOPCIFamily, the next step was:
    • Replace IOPCIFamily.kext
    • Result: Everything works!
Discovery Stage 3:
Now it was a matter of comparing IOPCIFamily between early and late builds of 13.3. This effort was greatly facilitated by the Ghidra disassembler, which has an option to generate C-like pseudo code from a compiled x86 binary.

Comparing the disassembled code revealed two new functions: addMemoryRange and reserveRanges. The latter was examined first. It turns out that reserveRanges is the result of some minor refactoring of existing code, but it contains a little bit of new code as well. The first inclination was to patch-out the new code from this function, which is shown in the dotted box:
Screenshot 2023-04-03 at 6.03.31 AM.png

This did not work: The first patch failed and was discarded. Attention turned to the other new function addMemoryRange. To determine where this function is called from, it was simply a matter of searching the pseudo-code file in BBEdit:

Screenshot 2023-04-03 at 6.07.35 AM.png

We can see that addMemoryRange is newly added in late 13.3. Interesting. So what would happen if we magically erased this call? That was done by finding the relevant section in Hopper disassembler and replacing it with a series of No-Operations:
Screenshot 2023-04-03 at 6.11.49 AM.png
Screenshot 2023-04-03 at 6.13.55 AM.png

After applying this patch and rebooting, success.

Screenshot 2023-04-02 at 12.27.23 PM.png
Screenshot 2023-04-02 at 12.28.51 PM.png
Last edited:

Excellent detective work, many thanks for posting your explanation.

My bad, it was not; I didn't have Vt-D enabled in the BIOS. I've enabled now. The patch was necessary and working.

Still no private relay (private relay is unavailable), is this the same for everyone?
It seems to be okay for me:

Screenshot 2023-04-03 at 7.36.02 AM.png
@CaseySJ Thanks for your explanation. Now that the patch is released, documented and is being tested by various users, likely on a variety of systems as well, I suppose that the next step is a pull request to OpenCore.
@CaseySJ Thanks for your explanation. Now that the patch is released, documented and is being tested by various users, likely on a variety of systems as well, I suppose that the next step is a pull request to OpenCore.
As we can see here, this takes a lot of work and affects a handful of files. Me scared to mess with that. :)

Update: On second thought, it doesn't look too bad. Will create a private OpenCore build to test it out.
Last edited:
** Experimental OpenCore.efi with FixAppleVTD Kernel Quirk **
The patch to fix WiFi and Ethernet issues in macOS 13.3 has been incorporated directly into a test version of OpenCore that is attached to this post. This means it's not necessary to add the patch manually to config.plist.

Instead, a new Kernel Quirk called FixAppleVTD has been introduced that can be enabled and disabled as needed. When enabled, OpenCore itself will inject the patch into the right version of macOS.

This version of OpenCore.efi is based on the just-released OpenCore 0.9.1 code base, so it includes everything that's in 0.9.1.

  1. Disable the Kernel -> Patch if the patch has already been added and enabled.
  2. Replace existing OpenCore.efi in EFI/OC folder with the version attached below.
  3. Add these two lines (manually for now) into config.plist using a text editor as shown. The lines must be added in the Kernel Quirks section.
Screenshot 2023-04-03 at 11.52.05 AM.png

Save config.plist and reboot. Do WiFi and Ethernet continue to work?


    270.4 KB · Views: 58
Last edited: