CaseySJ
Moderator
- Joined
- Nov 11, 2018
- Messages
- 22,198
- Motherboard
- Asus ProArt Z690-Creator
- CPU
- i7-12700K
- Graphics
- RX 6800 XT
- Mac
- Classic Mac
- Mobile Phone
** Patch Theory **
Fixing WiFi and Ethernet in macOS 13.3 with AppleVTD
Fixing WiFi and Ethernet in macOS 13.3 with AppleVTD
Purpose:
As requested by some, this post explains how the patch was found and what the patch does.
Discovery:
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/Extensionswere replaced by those from an early 13.3 beta build - A Frankenstein hybrid was thereby created and it booted and worked perfectly
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!
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:
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:
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:
After applying this patch and rebooting, success.
Last edited:
