IntelLucy for the Intel X500 family

[Mieze]

@KGP-iMacPro As already stated many times before: For a driver to work properly with AppleVTD you need two things:

1. The driver must be designed to handle DMA using the IOMMU. IntelLucy does this.
2. A mainboard which is compatible with AppleVTD. Unfortunately some mainboards refuse to work stable with AppleVTD enabled even with a patched DMAR and it looks like you are affected of this issue.

Another point you should consider is the fact that Apple changed something with regard to AppleVTD in Tahoe (most likely 15.5 too) because there are serval reports of users which never had a problem with AppleVTD in the past, but have to disable it in Tahoe, whereas others, which haven't been able to use AppleVTD in the past, now report that AppleVTD is working in Tahoe (and/or 15.5). My GB Z490 Gaming X also is one of these boards (with 15.5 as I haven't tried Tahoe yet).

 

Mieze 😿

Edited June 29, 2025 by Mieze
Fixed typo

[kgp]

In conclusion of all my tests and our discussion:

 

IntelLucy.kext works with my onboard X550-AT2 NICs of the ASUS X299 SAGE 10G (BIOS Version 4701) under Tahoe Beta 2 only with the following procedure and kernel quirks DisableIoMapper <true>, DisableMapperMapping <false>:

 

 Enter BIOS -> Disable VT-D -> save -> reboot-> Enter BIOS -> Enable VT-D -> save -> Reboot -> Boot Tahoe -> Success 🤩

 

 

 

 

with: Ethernet 1 - IntelLucy, Ethernet - Intel AX210 Bluetooth/WIFI 

 

This VT-D BIOS RESET is a somewhat strange and a bit annoying approach but appears to work in principle… 

 

No DMAR modding, No DMAR dropping.

 

With the 2 kernel quirk settings above,  Intel AX210 Bluetooth/WIFI works as well.

 

I can live with this solution for now. 

 

@Mieze and @etorix, many thanks for all your help and clarifications !  

 

Edit: in addition I raised a ticket at ASUS:

Thank you for handling my support request.

First, here are my system specifications:

Mainboard: ASUS X299 Sage 10G, BIOS version 4701
CPU: Intel Core i9-7980XE
RAM: 128 GB Corsair Dominator Platinum DDR4
GPU: AMD Radeon VII
Thunderbolt: GC-Titan Ridge
Bluetooth/Wi-Fi: Broadcom BCM94360CD and Intel AX210
Monitor: LG 5K 34WK95U-W
Operating Systems: macOS Sequoia 15.5 and macOS 26.0 Developer Preview 2 (“Tahoe”)
Bootloader: OpenCore 1.0.5

Issue Description:

There is a critical issue when initializing the X550-AT2 onboard controllers under macOS Sequoia 15.5 and macOS 26.0 Developer Preview 2. This may be caused by a conflict between ASUS BIOS version 4701, VT-d, and Apple’s VT-d implementation.

The latest macOS versions ship with Apple’s native DriverKit-based driver:
com.apple.DriverKit-AppleEthernetIXGBE.dext
for Intel 10Gbit Ethernet controllers.

Problem:
This DriverKit extension crashes immediately upon loading and fails to initialize. The system logs show:

Exception Type: EXC_CRASH (SIGABRT)
Termination Reason: SIGNAL, Code 6 (Abort trap)
Function: IOUserNetworkEthernet::init() → panic() caused by __assert_rtn

As a result, the onboard X550 interfaces are not available in macOS, and no Ethernet connectivity is possible unless the DEXT driver loads successfully.

Workaround Using IntelLucy.kext (Community Driver):

As a workaround, the open-source IntelLucy.kext (a community fork of SmallTree/IntelIX) can partially initialize the X550 controller under macOS 15.5 and 26.0.

While the driver does load during boot, network connectivity is unreliable: the interface sometimes connects for a few seconds and then drops back to "disconnected" status.

A temporary workaround helps in some cases:

In BIOS, disable VT-d, save and reboot

Re-enter BIOS, enable VT-d again, save and reboot

Only then boot macOS

In addition, the following OpenCore kernel quirks are required:

DisableIoMapper: true
DisableMapperMapping: false

However, even with these steps, the connection is not stable – Ethernet may disconnect after sleep/wake cycles or system reboots and the vt-d BIOS reset workaround works sometimes but not always. 

My Questions for ASUS:

Are there any known compatibility issues or firmware problems with the X550-AT2 controller, especially regarding VT-d and Apple’s DriverKit implementation?

Is ASUS planning a BIOS update or firmware patch to improve DriverKit and VT-d compatibility under modern operating systems like macOS 15.5 and 26.0?

Would it be possible to provide an updated NIC firmware for the onboard X550 to resolve these issues?

I would be happy to provide kernel logs, system crash reports, or sample data upon request and am available for any further testing or feedback you may need.

Thank you very much in advance for your assistance.

Suggestions what else to add to this ticket are highly appreciated. So far the initial request has been forwarded to the 2nd Level Team.

 

 

Edited June 30, 2025 by KGP-iMacPro
new ticket at ASUS

[etorix]

So VT-d off…

macOS not being offcially supported on the board, I'd be surprised if the ticket got anywhere. But we shall see.

[kgp]

On 6/30/2025 at 6:48 PM, etorix said:

So VT-d off…

macOS not being offcially supported on the board, I'd be surprised if the ticket got anywhere. But we shall see.

After further testing, I unfortunately I have to discard the above findings concerning the IntelLucy.kext functionality with the proposed vt-d BIOS reset approach under Tahoe. With kernel quirks DisableIoMapper <true> (no AppleVTD),  IntelLucy.kext successfully connects to LAN/internet just randomly and occasionally even without doing anything, just with Vt-D enabled in the BIOS.

 

 

 

In contrary, with DisableIoMapper <false> ( with AppleVTD), I randomly and occasionally reach the status of Ethernet 1: Self-assigned IP without any connection to LAN or Internet.

 

 

 

BTW.. My ticket to ASUS has been rejected at first instance, with the expected argumentation that ASUS does not support macOS. In a reply, I referred to my previous collaboration with ASUS back to 2018 in successfully reviving the Disable MSR lock BIOS functionality on ASUS mainboards. Now the ticket is again in progress, but I won't post here anything further except in case of another rejection, not to endanger any likely help or collaboration.  

 

Edited July 2, 2025 by KGP-iMacPro

[kgp]

 

@etorix, two rejections from ASUS Germany. Unable to contact ASUS U.S. from here, the ones who collaborated with me back in 2018.

 

Only thing left to try was reverting the EEPROM modding to natively inject the DEXT DriverKit. There have been several possibilities:

 

In the initial Ubuntu EEPROM modding, I just changed the original values of Subsystem Device ID to (for simplicity all terminal commands only for one NIC):

# Subsystem Device ID → 0x000A (SmallTree)
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x242 value 0x0a
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x243 value 0x00

to successfully load the SmallTreeIntel8259x.kext. I did not touch the Subsystem Vendor ID 0x240 und 0x241 which are by default 0x43 and 0x10.

 

I now reinstalled Ubuntu and reverted the Subsystem Device ID back to ASUS without any success in injecting the DEXT DriverKit:

# Subsystem Device ID (ASUS)
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x242 value 0x86
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x243 value 0x80

As a last try,  I changed everything to Intel, again without any success in injecting the DEXT DriverKit:

# Subsystem Vendor ID → 0x8086 (Intel)
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x240 value 0x86
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x241 value 0x80

# Subsystem Device ID → 0x1563 (X550-AT2)
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x242 value 0x63
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x243 value 0x15

Finally the fallback to the only working SmallTree solution with KPs under Tahoe 

# Subsystem Vendor ID → 0x8086 (Intel)
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x240 value 0x86
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x241 value 0x80

# Subsystem Device ID → 0x000A (Smalltree)
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x242 value 0x0a
sudo ethtool -E enp225s0f0 magic 0x15638086 offset 0x243 value 0x00

I hope that you agree with the values above or do you have any other suggestion?

 

Thanks for all your help 👍

 

Edited September 4, 2025 by KGP-iMacPro
Final results

[etorix]

This looks correct, but without working VT-d there can be no native support by DriverKIt, and @Mieze said that IntelLucy.kext, which does not depend on AppleVTd, does not check for subsystem IDs. I don't know where the issue is…

[kgp]

On 7/4/2025 at 8:57 AM, etorix said:

This looks correct, but without working VT-d there can be no native support by DriverKIt, and @Mieze said that IntelLucy.kext, which does not depend on AppleVTd, does not check for subsystem IDs. I don't know where the issue is…

@etorix, @Mieze

 

AppleVTD / IOMMU fully functional under macOS 26 (Tahoe)

 

Running macOS 26.0 DP2 (Tahoe) on an ASUS X299 Sage 10G with Intel X550-AT2 NICs.
VT-d is enabled in BIOS, and OpenCore 1.0.5 is configured with:

• DisableIoMapper = false

• DisableMapperMapping = false

AppleVTD is loaded and active:

 

kmutil showloaded | grep -i AppleVTD

kgp@Mac-Pro ~ % kmutil showloaded | grep -i AppleVTD
  175    0 0xffffff7f950fd000 0x2fe0     0x2fe0     com.apple.driver.AppleVTD (1.0) 1A2B3C4D-1234-5678-9ABC-DEF012345678 <...>

 

Both NICs are correctly assigned to the VT-d domain:

ioreg -lw0 -c AppleVTDDevice | grep -E 'XGBE|XGBF|IOMMUUnit|pciclass'

IOService:/.../PC03@0/BR3D@30000/IOMMUUnit@0
 ├── XGBE@0 (pci8086,1563)
 └── XGBF@1 (pci8086,1563)

Conclusion:

• AppleVTD.kext is present and fully operational

• IOMMU/VT-d device assignment works as expected

• No misconfiguration or VT-d issues

However:
LAN/internet still fails due to:

• IntelLucy.kext not able to connect to LAN/Internet

• Crashing com.apple.DriverKit-AppleEthernetIXGBE.dext

I guess this is rather a driver-layer problem, not a VT-d or platform issue. LAN/internet connection still fails due to higher-layer driver issues (IntelLucy.kext, Apple DEXT crashes), not because of missing VT-d or IOMMU.

 

That's all from my side for now. btw.. I am not available  the next 2 days (holidays without internet 🙂)

 

 

[etorix]

14 minutes ago, KGP-iMacPro said:

IOService:/.../PC03@0/BR3D@30000/IOMMUUnit@0

"IOMMUUnit" is not valid ACPI name. If this is the issue, the solution should be a SSDT to give a proper name to the chlld at address 0 under PC03.BR3D.

[kgp]

Findings on Apple IXGBE DEXT in macOS 15/26

 

I inspected the current com.apple.DriverKit-AppleEthernetIXGBE.dext (macOS Sequoia / Tahoe).

 

Observations:

1. No more IOPCIPrimaryMatch

   • Previous kexts contained IOPCIPrimaryMatch entries (e.g. 0x1528 = X540, 0x151c = X520).

   • The current DEXT has none at all.

   • That means it no longer binds directly via PCI IDs.

2. Why X520/X540 still might attach

   • Apple uses internal routines in IONetworkingFamily / system configuration.

   • These devices are still supported because they shipped in real Macs (MacPro5,1 / 6,1).

3. X550 is excluded

   • Device ID 0x1563 (X550) is not detected, as it was never used in Macs.

   • Even if IDs were added manually, the DEXT lacks initialization for the 10GBase-T PHY, so link negotiation would likely fail.

4. Conclusion

   • The Apple IXGBE DEXT seems not a path forward for X550 support.

   • Focus for development and testing should remain on IntelLucy.

Summary:

The IXGBE DEXT no longer contains PCI ID matches and only supports legacy hardware (X520/X540) through Apple’s internal exceptions. X550-AT2 cannot be enabled with this DEXT.

 

Current IntelLucy Behavior on X550-AT2 (Sequoia/Tahoe)

• Device attaches and shows up in System Information.

Intel X550-AT2 10-Gigabit Ethernet:

  Bus:	PCI
  Vendor ID:	0x8086
  Device ID:	0x1563
  Subsystem Vendor ID:	0x8086
  Subsystem ID:	0x1563
  Revision ID:	0x0001
  PCIe Link Speed:	8.0 GT/s
  PCIe Link Width:	x4
  PCIe Slot:	Built In
  Driver:	com.insanelymac.IntelLucy
  BSD Device Name:	en0
  MAC Address:	0c:9d:92:c4:35:83
  AVB Support:	No
  Maximum Link Speed:	10 Gb/s

 

Observed Behaviour

 

• The interface (en0) is created, MAC address is valid, driver reported as com.insanelymac.IntelLucy.

• After boot, Ethernet 1 (en0) shows "Not connected".

• Occasionally, after manually opening System Preferences -> Ethernet -> Details -> Hardware, the interface may switch to "self-assigned" after some time

• ifconfig shows inactive with:

media: autoselect (<unknown type>)
status: inactive
link rate: 10.00 Gbps
agent domain: Skywalk type:NetIf / FlowSwitch

• Manual media settings in System Preferences (10Gbase-T full-duplex, Jumbo) are sometimes accepted but then revert back, never stabilizing the interface.

• netstat -ib confirms: no TX or RX packets are ever counted, even with static IP assignment.

• Kernel logs show IOPCIDevice::handleClose() triggered after attach, meaning the PCI device is closed prematurely.

• Changing ACPI/VT-d settings (DMAR, DisableIoMapper) does not affect behaviour.

•  Sandbox violations in logs (duetexpertd / managedcorespotlightd) are unrelated to link issues.

 

Analysis

1. PHY works – manual 10G link confirms hardware is functional.

2. Interface remains inactive – macOS rarely receives a proper “interface up” notification via IntelLucy.

3. No data path – macOS never gets a working TX/RX channel; packets do not reach the NIC.

4. Likely cause – missing or incomplete X550-specific 10GBase-T PHY initialization and/or attachInterface / enable() logic in IntelLucy.

5. Skywalk stack – interface appears in userspace networking, not classic BSD Ethernet → status inactive even if link physically up.

 

---

Summary

• IntelLucy successfully attaches to X550-AT2 and negotiates 10G link, but: Interface remains inactive, no packets TX/RX, Likely missing X550-AT2-specific PHY initialisation in IntelLucy.  

• Dropping DMAR and/or DisableIoMapper (true/false) does not improve the situation 

• Likely missing or incomplete PHY initialization (10GBase-T specific).

• Stable support for X550-AT2 might require additional initialisation logic and working Skywalk integration.

 

Recommendations / Next Steps:

 

1. Implementation of full X550-AT2 PHY initialization in IntelLucy to ensure proper 10GBase-T link negotiation.

2. Fix of attachInterface / enable() logic so macOS consistently receives “interface up” notifications.

3. Verification of Skywalk integration to ensure the interface is properly recognized in both userspace networking and BSD layer.

4. Stabilization of manual media settings (10Gbase-T, full-duplex, Jumbo) so changes persist and do not revert automatically.

5. ACPI / VT-d: No changes to DMAR / DisableIoMapper appear effective at least in case of X550-AT2.

6. Community Testing: Collecting reports from other X550-AT2 users for patterns in self-assigned IP behavior, intermittent link activation, and media negotiation.

Edited September 4, 2025 by KGP-iMacPro

[etorix]

Nice investigation work… for a disppointing result.

I tought that the dext drivers were meant to broadly support 10+ Gb/s NICs in Thunderbolt enclosures for Macs or even iPads; mlx5 is certainly intended that way, as no Mac ever used a ConnectX chip. (I'm less sure about X710 and ixl.)  It is a real pity that ixgbe is locked down to particular NICs used in Macs.

[kgp]

On 8/30/2025 at 10:06 PM, etorix said:

Nice investigation work… for a disppointing result.

I tought that the dext drivers were meant to broadly support 10+ Gb/s NICs in Thunderbolt enclosures for Macs or even iPads; mlx5 is certainly intended that way, as no Mac ever used a ConnectX chip. (I'm less sure about X710 and ixl.)  It is a real pity that ixgbe is locked down to particular NICs used in Macs.

 

As the kext does not contain any IOPCIPrimaryMatch entries neither in macOS 15.6 nor macOS 26 , it is difficult to estimate which 10+ Gb/s NICs are still matched by the dext driver. The driver actually behaves like a black box and patching the EEPROM with IDs that might suite the driver seems therefore nearly  impossible. I hope I am just wrong in my conclusions above and somebody else will show up and confirm a successful X550-AT2 implementation with the dext driver. 👍 

Edited September 8, 2025 by KGP-iMacPro

[Mieze]

Sorry for the delayed answer but I've been very busy during the last week, so that I totally forgot to answer. I used several X520 cards and a X540 to test with. IntelLucy comes with the necessary code to initialise copper PHYs found in cards with RJ-45 ports and I successfully verified that both ports of my X540-T2 are working, but I haven't tested it with an X550 because I don't have one. These cards are still quite expensive compared to the X520 and X540 and I was hesitating to buy one for testing. After rethinking my decision during the last days, I finally decided to order a card for test purposes. I'm going to run some test and fix any problems I can find. Delivery is scheduled for next week and I'll report back ASAP.

 

Mieze

[kgp]

On 9/3/2025 at 10:10 PM, Mieze said:

Sorry for the delayed answer but I've been very busy during the last week, so that I totally forgot to answer. I used several X520 cards and a X540 to test with. IntelLucy comes with the necessary code to initialise copper PHYs found in cards with RJ-45 ports and I successfully verified that both ports of my X540-T2 are working, but I haven't tested it with an X550 because I don't have one. These cards are still quite expensive compared to the X520 and X540 and I was hesitating to buy one for testing. After rethinking my decision during the last days, I finally decided to order a card for test purposes. I'm going to run some test and fix any problems I can find. Delivery is scheduled for next week and I'll report back ASAP.

 

Mieze

 

Hi @Mieze,

IntelLucy with my Intel X550-AT2 NICs on an ASUS X299 Sage 10G under macOS Sequoia 15.6.1 and macOS 26 DP9 (Tahoe) – current status:

 

With focus on Sequoia 15.6.1, I reached the first reproducible results under a  almost working configuration:

 

Sequoia 15.6.1

• DHCP currently doesn’t work on my router (independent of the driver), so I’m using manual TCP/IP and DNS settings.

• Link negotiation is unstable: en0 toggles between ~5s red (“not connected”) and ~1s green (“connected”) until it finds a stable connection.

• Hardware configuration (Speed 10Gbase-T, full-duplex, MTU 9000) can be set, but IntelLucy often resets them to “Automatically”.

• Using SmallTree.kext instead, link and connection are stable, manual TCP/IP and DNS persist, hardware settings remain, and Internet connection is reliable.

 

macOS 26 DP9 (Tahoe)

• IntelLucy cannot switch TCP/IP to manual: it immediately reverts to DHCP.

• If manual TCP/IP + DNS is first configured with SmallTree, IntelLucy preserves these values.

• IntelLucy still exhibits the same red/green toggling until it finds a stable connection.

• SmallTree proves the NIC can maintain stable 10Gbase-T full-duplex with MTU 9000, but driver instability (kernel panics) prevents its use under Tahoe.

 

Technical Notes

• IntelLucy sometimes resets ifconfig media settings (speed/duplex/MTU), while SmallTree keeps them stable.

• Red/green toggling indicates PHY link state detection or watchdog issues with the X550.

• Manual IP/DNS persistence works in Sequoia; Tahoe forces DHCP with IntelLucy active if not set to "Manually" with Smalltree.kext previously.

• Tests with modified DMAR and DisableIOMapper true/false showed no difference.

 

Suggested Investigation Points

 

1. Verify PHY initialization and watchdog logic for X550 copper PHYs.

2. Ensure manual hardware settings (speed/duplex/MTU) persist during IntelLucy initialization.

3. Investigate IntelLucy behavior causing DHCP fallback under Tahoe.

4. Check for PCI/IOKit assumptions that affect X550 behavior.

5. Consider optional verbose logging for PHY state, link negotiation, and media changes.

 

Setup Details / Possible Pitfalls

 

My Hackintosh connects via en0 → Netgear ProSafe XS5508M 10G switch → Fritz Repeater → Fritz Box (router) upstairs (LAN-over-Wi-Fi). This topology might impact IntelLucy’s PHY link negotiation and speed/duplex detection. SmallTree.kext handles this reliably.

 

Thanks a lot for your continuous work – and really great news that you’ve ordered an X550 for testing! Please let me know if and how I can contribute to this purchase and make a donation for your brilliant work and collaboration in general.

 

Best regards,
kgp

 

Update: DHCP is now working correctly again with my setup, so manual TCP/IP is no longer strictly required, but helps IntelLucy in establishing a connection. IntelLucy always toggles the link status (red/green) during initialisation before establishing a connection. This toggling may disrupt DHCP on the router or switch. After this, even SmallTree cannot obtain a lease until both the router and switch are power-cycled. Else, DHCP with Smalltree works flawless. 

Edited September 5, 2025 by KGP-iMacPro

[Mieze]

I've got good news to report. Yesterday evening the X550 I ordered somedays ago arrived. It's a card from ipolex but the box shows 10Gtek as the manufacturer, so that I assume that it's just a rebranded card, identical to the original 10Gtek model.

 

 

I removed the X540 card from my test system and installed the X550, booted the system and it worked reliable OOB, in the same way as the X540. I tested under Monterey and Sequoia with the latest version of IntelLucy. I checked 10Gbase-T, 5Gbase-T and 2.5Gbase-T and can confirm that these speeds are working. As the card seems to be a clone of Intel's reference design, most X550 cards should also work. I performed some basic tests, like surfing, copy operations in finder and a full Time Machine backup, without discovering any problems. 

@KGP-iMacPro I need more information about your system in order to find out, why your onboard NICs on the ASUS X299 Sage are still exhibiting such a strange behaviour. Maybe it's because they don't use the X550's integrated PHY, like most add-on cards do, but an external one. That's why I would like to ask you to collect some additional information for me. Please boot your system with a Linux live USB stick, run the following comas and send me the output. As the X550 on your board might have a different interface name, you should check the interface names first and adapt the commands so that they match your NIC's interface name. Thanks in advance!

sudo lspci -vvv

sudo ethtool enp2s0f0

sudo ethtool -d enp2s0f0

Mieze 😺

Edited September 6, 2025 by Mieze
Fixed a typo

[kgp]

Hi @Mieze,

 

first of all, many thanks for ordering, installing, and testing the X550 card on your system. Very kind, really! 🙏 Just for the sake of coherence: I performed all tests under macOS with actual IntelLucy.kext v. 1.1.1 release from Github.

 

I’ve prepared a complete set of requested information of my ASUS X299 Sage 10G system with the onboard X550-AT2 NICs. The information has been gathered under Ubuntu 16.04.7 LTS, which I have installed for EEPROM modding. All files are in the ZIP I’m sharing.

 

Below is a breakdown of each file, its purpose, and the command I used to generate it.

 

Main Mieze folder:

• dump_enp225s0f0.txt – Low-level driver dump of enp225s0f0 (sudo ethtool -d enp225s0f0).
• dump_enp225s0f1.txt – Low-level driver dump of enp225s0f1 (sudo ethtool -d enp225s0f1).
• eeprom_enp225s0f0.bin – Raw EEPROM dump of enp225s0f0 (sudo ethtool -e enp225s0f0 raw on).
• eeprom_enp225s0f0.txt – Human-readable EEPROM dump of enp225s0f0 (sudo ethtool -e enp225s0f0).
• eeprom_enp225s0f1.bin – Raw EEPROM dump of enp225s0f1.
• eeprom_enp225s0f1.txt – Human-readable EEPROM dump of enp225s0f1.
• ethtool_enp225s0f0.txt – General interface info of enp225s0f0 (sudo ethtool enp225s0f0).
• ethtool_enp225s0f1.txt – General interface info of enp225s0f1.
• lspci_vvv.txt – Full PCI information for all devices (sudo lspci -vvv).

Addon folder (~/Mieze/addon):

• dmesg_enp225s0.txt – Kernel messages filtered for my X550-AT2 interfaces (dmesg | grep enp225s0).
• dmesg_ixgbe.txt – Kernel messages filtered for the ixgbe driver (dmesg | grep ixgbe).
• ethtool_i_enp225s0f0.txt – Driver info for enp225s0f0 (sudo ethtool -i enp225s0f0).
• ethtool_i_enp225s0f1.txt – Driver info for enp225s0f1.
• ethtool_version.txt – Installed version of ethtool (ethtool -V).
• lsb_release.txt – Linux distribution information (lsb_release -a).
• modinfo_ixgbe.txt – ixgbe driver module info (modinfo ixgbe).
• uname.txt – Kernel version and architecture (uname -a).

I hope this gives you all the information you need to investigate the onboard NICs of my ASUS X299 Sage 10G.

 

Please let me know if you need anything else!

 

Best regards,

 

kgp👍

 

Mieze.zip

Edited September 7, 2025 by KGP-iMacPro
Adding information concerning Intellucy version in use for testing under macOS

[Mieze]

@KGP-iMacPro Thanks for the data! There is nothing special with your NIC. It uses the internal PHY like mine. Everything seems to be normal, but I've been able to reproduce your problem. After waking up from sleep, the X550 sometimes gets into an unstable state, so that it establishes a link but after 2 seconds the link is lost again and the cycle keeps repeating until it is terminated by pulling the cable. After pulling the cable, I have to wait a few seconds until I replug it to resolve the problem. After that the link is reestablished and stable. I will have to review the sleep/wake related code to find out what is going on. The strange thing is that the X540 isn't much different with regard to the PHY but it doesn't exhibit this strange behaviour. I'll report back as soon as I find something or have a debug version ready for further tests.

 

EDIT: Please verify in the UEFI setup that the UEFI network stack is disabled to prevent it from taking control of the NIC because it's an onboard LAN unit. Also check that any remote management function is disabled in UEFI in case your UEFI supports this function.

 

Mieze 😺

 

Edited September 7, 2025 by Mieze
Added comment about UEFI setup

[kgp]

Edit on 09.09.2025:

 

Hi @Mieze, it seems you have reproduced only part of my problem. On my X550, the link toggle issue with IntelLucy doesn’t just occur after sleep/wake - it already appears right after boot and/or after deactivating/activating Ethernet 1 (en0). IntelLucy establishes via DHCP a valid link for a second with valid TCP/IP and DNS values via DHCP (Ethernet 1 - green) but looses the link immediately afterwards for 5 to 10 seconds (Ethernet 1 - red) until the same procedure starts right from the beginning.

 

Under Sequoia, this cycle only reproducibly stops if I set TCP/IP and DNS to manual (after deactivating Ethernet 1). In addition, changing the hardware settings (speed/duplex etc.) during the toggling of the Ethernet-1 interface using IntelLucy might help in establishing a successful link. However, most of the time, these settings reset themselves automatically by IntelLucy. Interestingly, after a final successful connection with IntelLucy, Ethernet-1 sometimes may remain green, but the PC loses internet connectivity after ~30 seconds. In such cases, also SmallTree.kext won't work subsequently with DHCP or manual TCP/IP settings unless I reboot the switch and/or router. Under Tahoe, the link toggle is infinite, independently of DHCP on/of and any change of "Hardware"  Settings.  

 

Could you please check how your X550 behaves when toggling the interface manually via "Make inactive" / "Make active" in the System Settings? I expect it might work correctly for you, since your card connects immediately after boot. With IntelLucy, my X550 onboard NICs seem to have a rather general PHY initialization/state problem than a Sleep/Wake issue. However, by finding the culprit for the link toggle of your X550-AT2 after sleep/wake with IntelLucy under Sequoia, you might be able to expand the necessary changes globally in your code, which in consequence might also help my X550 NICs in successfully establishing a link via DHCP directly after boot or after deactivating/activating Ethernet 1 (en0) subsequently.  

 

BTW.. are we both using the same version of IntelLucy (v.1.1.1) for our tests?

 

Best regards, KGP

Edited September 9, 2025 by KGP-iMacPro
Rewriting the correspondence to be more explicit. Please reread!

[Mieze]

@KGP-iMacPro Have you checked the UEFI settings I asked you to verify? The problem might be related to the driver / firmware coexistence mechanism. I remember a similar problem with IntelMausiEthernet on LM-versions (with management firmware) of the I219-chips years ago. The problem was that the driver took control of the NIC late in the initialisation process and released it during sleep with the result that certain configurations din't work at all or failed to resume work after wakeup, which reminds me of our problem. The solution was to take control early in the initialisation process and keep it while sleeping. 

[kgp]

@Mieze, I’ve double-checked all BIOS/UEFI settings relevant to the onboard Intel NICs on my ASUS X299 Sage 10G (BIOS 4701):

 

• Intel LAN Controller: Enabled (both onboard ports active and cannot be switched on/off separately)
• Intel LAN PXE Option ROM: Disabled (no preboot network)
• Network Stack: Disabled
• Wake-on-LAN: Not separately configurable
• Link speed, duplex, and similar NIC settings: Not configurable in BIOS/UEFI (driver auto-negotiation only); Only NIC Configuration: Blink Leds 0 

 

Additionally, I was never able to update to the latest Intel ME firmware, since I don’t have a Windows environment available for the update. I don't know if this matters somehow.

 

Anyway, all NIC functions - including DHCP, manual TCP/IP configuration, hardware link settings, link lease, and Internet connectivity - work with the SmallTree.kext despite the annoying KPs under Tahoe. Thus, the BIOS settings should not be any issue.

 

Update - listing of BIOS settings attached below:

 

04092025_BIOS_settings.txt

 

Edited September 7, 2025 by KGP-iMacPro
Adding listing of BIOS settings

[Mieze]

@KGP-iMacPro First of all, to avoid any further discussions about boot and wakeup, the driver has to go through the same initialisation code on boot and while waking up. If the problem shows up in one of these situations, the other one is almost certainly affected too.

 

I've spent the las two days investigation the issue. It looks like there is a race condition in the initialisation code. In certain unknown situations the PHY gets in a state, in which the established link is always unstable, so that the link is lost within a few seconds and the up/down cycle keeps repeating until the PHY is power-cycled. I haven't been able to identity the exact reason but the fact that it occurs only sometimes is a strong indicator for a race condition.

 

Anyway, I managed to find a work-around to recover from that situation. When the link is lost within the first 4 seconds after the link up event, the PHY is powered down for 5 seconds before it gets powered on again. This seems to break the cycle and reestablishes normal operation. I'm currently testing the patch and will publish it as ASAP, provided that a few days of real world testing will confirm that it's working as expected.

 

Mieze 😺

[kgp]

@Mieze, thanks a lot for digging into this! Your explanation about the race condition in the initialization code makes a lot of sense. I’m looking forward to testing your patch once it’s ready.

 

By the way, just for completeness: does the native Apple DEXT com.apple.DriverKit-AppleEthernetIXGBE actually load and work with your X550-AT2 under macOS 15.6.1 or 26 RC? I noticed your subsystem IDs are 0x1dcf/0x0314. I had tried patching mine to 0x8086/0x1563 as a blind guess, but the DEXT still didn’t attach. Curious if it works on your setup - just to round out our investigation.

 

KGP 

Edited September 10, 2025 by KGP-iMacPro

[Mieze]

@KGP-iMacPro The card also works with the native Apple DEXT com.apple.DriverKit-AppleEthernetIXGBE under 15.6.1, but I haven't tried Tahoe at all.

[Mieze]

Here is a first test version (built 1.1.308), which solved the problem for me. In case the PHY is unable to negotiate a stable link, it power-cycles the PHY to recover from that situation, which takes about 7 seconds.  Good luck testing!

 

Mieze 😺

IntelLucy-1.1.308.zip

[kgp]

Intel X550-AT2 + Apple DEXT + IOMMU/VT-d on ASUS X299 Sage 10G – Status Update

Mieze successfully got her X550-AT2 NIC running with com.apple.DriverKit-AppleEthernetIXGBE.

On my system, I patched the EEPROM of my X550-AT2 to match her card IDs and ran tests with macOS 15.6.1 & 26 RC. SSDT was extended with properties such as device-managed, iommu-selection, and IOServiceDEXTEntitlements.

 

Results:

 

• AppleVTD.kext loads, IOMMU/VT-d is generally active. Other devices bind correctly.
• X550-AT2 NICs refuse IOMMU assignment → DEXT does not load stably, even though ID properties appear correct in IORegistry.
• Previously, in a one timer event, the NICs seemed correctly integrated into the VT-d tree, but this is currently not reproducible – behaviour likely depends on root port topology, BIOS, or timing.

 

IntelLucy.kext remains the only “nearly” stable solution for my onboard X550-AT2 NICs.

 

PHY / IntelLucy Patch:

 

Mieze’s PHY-toggle patch (1.1.308) automates the PHY power-cycle to stabilise the link after wake.

On my setup (DisableIOMapper = true / VT-d not functional), the patch does not reliably break the toggle cycle. After boot, the NIC is generally without any connection using DHCP or it still toggles between green (connection) and red (no connection)). A possible connection can be established using the following procedure:

• Make inactive
• Details → Configure IPv4 “Manually” → Configure IPv6 “Manually”
• Hardware “Manually” → Speed 10GBase-T, Full-Duplex, Jumbo (9,000)
• Make active → starts a toggle every ~7 seconds until the NIC eventually establishes a stable link

This manual procedure essentially simulates the PHY power-cycle that the patch is intended to automate anyway. On my system, the patch might not be able to reliably trigger this cycle due to VT-d/IOMMU limitations (DisableIOMapper=true due to the unsatisfactory results with respect to IOMMU).

 

SmallTree.kext:

 

Under macOS 15.x / Sequoia → all functions stable, no issues.

Under macOS 26 / Tahoe → PHY + link remain stable, but Kernel Panics occur, likely due to Kext incompatibility with the Tahoe kernel.

 

Conclusion:

 

• SSDT/property patching alone is insufficient to achieve IOMMU assignment of the NICs and allow the DEXT to load reliably (attached my SSDT attempts for IOMMU/DEXT functionality).
• IntelLucy.kext remains the only “nearly” stable solution for my onboard X550-AT2 NICs under Tahoe.
• PHY-toggle patch should stabilize IntelLucy initialization in principle, but VT-d/IOMMU limitations on my system might prevent it from being fully effective, and the NIC may require manual intervention after boot to establish a stable link.
• SmallTree provides best link stability, but produces a KP problem under Tahoe. IntelLucy or DEXT are better alternatives, but on my setup they still encounter PHY / VT-d / IOMMU initialisation and toggling issues.

 

Sorry for not providing more positive news regarding my system.. 🤒 congrats and many thanks to @Mieze and @etorix anyway!! Any further help would be  highly welcome and more than appreciated...

 

SSDT-X299-ETH.aml

Edited September 12, 2025 by KGP-iMacPro

[Mieze]

@KGP-iMacPro Try the attached version. The problem might be related to the NIC advertising support for Nbase-T when doing auto negotiation as this comment in the linux source indicates:

            /* remove NBASE-T speeds from default autonegotiation
             * to accommodate broken network switches in the field
             * which cannot cope with advertised NBASE-T speeds
             */

In the attached version I disabled 2.5G and 5G support when auto negotiation is selected (default). Good luck testing!

 

Mieze 😺

IntelLucy-1.1.313.zip

Edited September 12, 2025 by Mieze