IntelLucy for the Intel X500 family

[Bradamante]

Say, how stable is this driver in everyday practice? I mean a 10 Gb/s network card would be a good fit for video production houses, but obviously those people need stability.

[Mieze]

@Bradamante It's ready for productive use. I'm using it on all of my Hackintoshs for almost a year now and it works reliable.

[kgp]

@Mieze , thanks for the possibility to post in this thread.  

 

I am facing severe issues with the X550-AT2 NiCs of my Asus x299 Sage 10G Bios vers. 4701 under Tahoe. In former macOS versions, including Sequoia, I could use the SmallTreeIntel8259x.kext thanks to an Ubuntu EEprom modding. Now under Tahoe, unfortunately this driver appears to be broken, causing random KPs.

 

I therefore decided to change to IntelLucy.kext version 1.1.1. However, with your kext I am also facing several issues concerning working/not working LAN and internet connection both under Sequoia and Tahoe:

 

1.) vt-d disabled in BIOS-> no LAN and internet connection at all;

 

2.) with vt-d enabled in BIOS, modded dmar.aml (SSDTTime) and DisableIOMapper/DisableIOMappermapping kernel quirks enabled in the config.plist, I only have internet and LAN, if I disable and reenable vt-d in the BIOS before each boot of my system.

 

If I do not apply the latter vt-d BIOS trick before each boot, IntelLucy.kext permanently connects for a second to LAN/internet and immediately falls back to no connection. 

 

In contrary, Lan and internet connection always work with the SmallTreeIntel8259x.kext under Sequoia and Tahoe, but with the disadvantage of KPs under Tahoe. 

 

Anything I could do in addition to make IntelLucy.kext permanently work on my system? Any recommendation or help would be much appreciated!

 

Liebe Grüsse aus Berlin,

 

KGP

Edited June 27, 2025 by KGP-iMacPro

[etorix]

8 hours ago, KGP-iMacPro said:

with vt-d enabled in BIOS, modded dmar.aml (SSDTTime) and DisableIOMapper/DisableIOMappermapping kernel quirks enabled in the config.plist

What do you mean exactly here?

DisableIoMapper disables VT-d, so this quirk should be OFF. DisableIoMapperMapping, however, may be used with VT-d on.

You have a workstation-class system; I have only limited experience with C422 and none at all with X299, but I'm not sure whether there's anything to do with DMAR here.

[kgp]

30 minutes ago, etorix said:

What do you mean exactly here?

DisableIoMapper disables VT-d, so this quirk should be OFF. DisableIoMapperMapping, however, may be used with VT-d on.

You have a workstation-class system; I have only limited experience with C422 and none at all with X299, but I'm not sure whether there's anything to do with DMAR here.

 

I always used DisableIoMapper and DisableIoMapperMapping kernel quirks enabled for my tests and either enabled or disabled vt-d  in the BIOS. Such settings have been proposed to me by other users here in this forum, as well as the additional test with a DMAR table modded with SSDTTime.

 

Open for any further suggestions and tests proposed from your side 👍 and many thanks for any help you could offer in this direction.

 

Edited June 27, 2025 by KGP-iMacPro

[Mieze]

@KGP-iMacPro Well, it's always best to leave VT-d enabled in UEFI and use DisableIoMapper to disable AppleVTD. This configuration should work on any system with IntelLucy. Next step should be to set DisableIoMapper to false without a patched DMAR and see what happens. If it doesn't work, try to patch the DMAR and drop the original one. Keep in mind that dropping the DMAR without injecting a new one effectively disables AppleVTD and that a patched DMAR also may cause KPs.

 

One more thing: Apple changed AppleVTD in Tahoe (maybe 15.5 too) with the result that several system which used to work fine in the past, now refuse to work, whereas other now work with AppleVTD which refused in the past.

 

In case you get a KP, please upload a photo of it!

 

Mieze

[kgp]

15 hours ago, Mieze said:

@KGP-iMacPro Well, it's always best to leave VT-d enabled in UEFI and use DisableIoMapper to disable AppleVTD. This configuration should work on any system with IntelLucy. Next step should be to set DisableIoMapper to false without a patched DMAR and see what happens. If it doesn't work, try to patch the DMAR and drop the original one. Keep in mind that dropping the DMAR without injecting a new one effectively disables AppleVTD and that a patched DMAR also may cause KPs.

 

One more thing: Apple changed AppleVTD in Tahoe (maybe 15.5 too) with the result that several system which used to work fine in the past, now refuse to work, whereas other now work with AppleVTD which refused in the past.

 

In case you get a KP, please upload a photo of it!

 

Mieze

 

@Mieze, first at all thanks for quick response. Well, VT-d enabled in UEFI and DisableIoMapper enabled seems not to work with IntelLucy on my system - No Lan or internet at all, although the driver is properly implemented. With VT-d enabled and DisableIoMapper disabled itlwm.kext (Intel AX210 Bluetooth/WIFI) won't load during boot. I already extracted the original dmar.aml with opencore,  patched the original dmar.aml with SSDTTime and added the modded dmar.aml in /EFI/OC/ACPI/ and config.plist under /ACPI/Add/. Is there anything else I have to implement in the config.plist to drop the original DMAR rather than only adding the modded dmar.aml to /EFI/OC/ACPI and config.plist?

 

I don't get any KP, and the driver is well implemented on my system. MY system just won't connect to LAN and internet, with the exception that it works , if I boot once with vt-d disabled and subsequently with vt-d enabled in the BIOS. Otherwise Ethernet 1 in System settings repeatedly connects for a second and immediately falls back to no connection.

 

Same behaviour under Tahoe and Sequoia. It is really a weird behaviour and I am spending on this issue already several days of investigation without any final solution. 

Edited June 28, 2025 by KGP-iMacPro

[Mieze]

@KGP-iMacPro To replace the existing DMAR you also have to add an entry in the ACPI->Delete section of the OC configuration file for the original DMAR to be dropped. Otherwise the patched DMAR won't be used as the original one is still in place.

[Mieze]

[kgp]

14 hours ago, Mieze said:

 

I extracted with ChatGPT AI and xxd ~/Desktop/DMAR/DMAR-original.aml | head -n 20  my  😀 the values below,  after many trial and errors..

 

kgp@Mac-Pro ~ % xxd ~/Desktop/DMAR/DMAR-original.aml | head -n 20                                  
00000000: 444d 4152 f800 0000 0197 414c 4153 4b41  DMAR......ALASKA
00000010: 4120 4d20 4920 0000 0100 0000 494e 544c  A M I ......INTL
00000020: 1310 0920 2d01 0000 0000 0000 0000 0000  ... -...........
00000030: 0000 2000 0000 0000 00c0 ffb5 0000 0000  .. .............
00000040: 0308 0000 0aa0 0504 0208 0000 00a0 0000  ................
00000050: 0000 2000 0000 0000 00c0 ffd8 0000 0000  .. .............
00000060: 0308 0000 0bc0 0504 0208 0000 00c0 0000  ................
00000070: 0000 2000 0000 0000 00c0 fffb 0000 0000  .. .............
00000080: 0308 0000 0ce0 0504 0208 0000 00e0 0300  ................
00000090: 0000 2800 0100 0000 00c0 ff9e 0000 0000  ..(.............
000000a0: 0308 0000 08f0 1f00 0308 0000 0900 0504  ................
000000b0: 0408 0000 0000 1f00 0100 2000 0000 0000  .......... .....
000000c0: 0050 734d 0000 0000 ffef 974d 0000 0000  .PsM.......M....
000000d0: 0108 0000 0000 1400 0200 2000 0000 0000  .......... .....
000000e0: 0208 0000 00a0 0000 0208 0000 00c0 0000  ................
000000f0: 0208 0000 00e0 0300                      ........
kgp@Mac-Pro ~ % 

 

 

I don't have EDK2 but AMI

 

			<dict>
				<key>All</key>
				<false/>
				<key>Comment</key>
				<string>Drop original DMAR</string>
				<key>Enabled</key>
				<true/>
				<key>OemTableId</key>
                                <data>QSBNIEkgAAA=</data>
				<key>TableLength</key>
				<integer>248</integer>
				<key>TableSignature</key>
				<data>
				RE1BUg==
				</data>
			</dict>

 

The equivalent to your OemTableId above would be: 

41204D20 49200000 

I use the same TableSignature though:

 

444D4152 

I crosschecked after each boot with the command below wether DMAR has been dropped or not:

 

log show --predicate 'eventMessage contains "OC: Dropping"' --last boot | grep DMAR

 

However, no success so far in dropping the DMAR Table...

 

!los gatos están comiendo mi cabeza! 😁

Edited June 28, 2025 by KGP-iMacPro
Update

[etorix]

15 hours ago, KGP-iMacPro said:

With VT-d enabled and DisableIoMapper disabled, my system won't boot at all.

Annoying, as this would be the ideal setting. (And your X550 card would then be supported natively by DriverKit, even though you might still want IntelLucy for additional options.)

Then try VT-d: enabled, DisableIoMapper: false, DisableIoMappingMapper: true.

If it still doesn't work, look into the DMAR table. Note that this table can be affected by hardware changes, RAM and new devices. But this class of system should have native tables that are suitable for virtualisation.

 

We should probably move that to a specific support thread as it is not structly realted to IntelLucy.

[Mieze]

@KGP-iMacPro You might want to use MacIASL to extract the original tables as this is the easiest way.

[kgp]

22 minutes ago, etorix said:

Annoying, as this would be the ideal setting. (And your X550 card would then be supported natively by DriverKit, even though you might still want IntelLucy for additional options.)

Then try VT-d: enabled, DisableIoMapper: false, DisableIoMappingMapper: true.

If it still doesn't work, look into the DMAR table. Note that this table can be affected by hardware changes, RAM and new devices. But this class of system should have native tables that are suitable for virtualisation.

 

We should probably move that to a specific support thread as it is not structly realted to IntelLucy.

 

I just checked once more,  "DisableIoMapper: false" indeed boots my system but just itlwm.kext (Intel AX210 Bluetooth/WIFI) won't load during boot. X550 supported natively by DriverKit?

Edited June 28, 2025 by KGP-iMacPro

[etorix]

Look into /System/Library/DriverExtensions/ 😉

macOS now ships with DEXT drivers ixgbe (for Intel X500 family), ixl (for Intel X700 family), and mlx5 (for Mellanox ConnectX-4 and later) NICs. We are spoiled for natively supported 10G, 25G and even some 100G NICs… provided that AppleVT-d works on our hacks. And Chelsio has released a DEXT version of cxgbe for its T5 and T6 lines.

 

Without VT-d, in particular for AMD hacks, we're limited to KEXT drivers, so Chelsio T5 and T6 with the Catalina-era kext and Intel X500 with IntelLucy—which may still be desirable over the native DEXT. 

 

If you can boot with VT-d, DisableIoMapper: false, and no IntelLucy, you may try and benchmark native X550 support. Then add IntelLucy.kext, which should take precedence over com.apple.DriverKit-AppleEthernetIXGBE.dext, and benchmark again.

Then we could look into itlwm.kext; this is where DisableIoMappingMapper could help. And as a last resort, making a custom DMAR; what's the native table?

Sanity check: Does itlwm already supports Tahoe? And have you adjusted your USB map for Tahoe?

1 hour ago, Mieze said:

You might want to use MacIASL to extract the original tables as this is the easiest way.

That, or the DEBUG version of OpenCore with Misc>Debug>SysReport: true (my favourite, as it works even without successfully booting into macOS).

[kgp]

6 hours ago, etorix said:

Look into /System/Library/DriverExtensions/ 😉

macOS now ships with DEXT drivers ixgbe (for Intel X500 family), ixl (for Intel X700 family), and mlx5 (for Mellanox ConnectX-4 and later) NICs. We are spoiled for natively supported 10G, 25G and even some 100G NICs… provided that AppleVT-d works on our hacks. And Chelsio has released a DEXT version of cxgbe for its T5 and T6 lines.

 

Without VT-d, in particular for AMD hacks, we're limited to KEXT drivers, so Chelsio T5 and T6 with the Catalina-era kext and Intel X500 with IntelLucy—which may still be desirable over the native DEXT. 

 

If you can boot with VT-d, DisableIoMapper: false, and no IntelLucy, you may try and benchmark native X550 support. Then add IntelLucy.kext, which should take precedence over com.apple.DriverKit-AppleEthernetIXGBE.dext, and benchmark again.

Then we could look into itlwm.kext; this is where DisableIoMappingMapper could help. And as a last resort, making a custom DMAR; what's the native table?

Sanity check: Does itlwm already supports Tahoe? And have you adjusted your USB map for Tahoe?

That, or the DEBUG version of OpenCore with Misc>Debug>SysReport: true (my favourite, as it works even without successfully booting into macOS).

 

Yea.. quite some time past since my X299 Mojave installation guideline and USB kext creation guideline, but a bunch of things are still valid though. I certainly did not catch yet all the new things since my disappearance from the community in 2019 and my return to Insanselymac a few weeks ago, e.g. that my X550-AT2 NICs should be implemented now natively by macOS. 

 

Everything what you write above sounds like a very good plan. So let's start at first place with trying to make the X550-AT2 NICs run natively. I will consider all your respective suggestions and report back whether or not I succeed with their native implementation.

 

Concerning itlwm.kext: the driver works with Heliport.app, both under Sequoia and Tahoe.

 

In also attach you my USB kexts, both doing also under Tahoe what they should do in principle. For Tahoe I made the proposed change of the kext, without any major improvement in kext performance or functionality.  

 

Last but not least, I attach the dmar.aml, which I extracted in opencore debug mode before implementing the intel AX210 PCIe Bluetooth/WIFI card, as well its modification with SSDTTime. 

 

 KGP-MacPro-ASUS-WSX299S10G-XHCI.kext.zip

 

KGP-MacPro-ASUS-WSX299S10G-XHCI-Tahoe.kext.zip

 

DMAR-original.aml

 

DMAR-modified.aml

 

And here the link to my recent EFI.

 

Many thanks for your help and that you want to guide me through this journey with my X550-AT2 NICs 👍

Edited June 28, 2025 by KGP-iMacPro

[etorix]

As I suspected, the only reserved region is for PCI address 14,00, which should be the USB controller. Removing it may do more harm than good.

[kgp]

7 hours ago, etorix said:

Look into /System/Library/DriverExtensions/ 😉

macOS now ships with DEXT drivers ixgbe (for Intel X500 family), ixl (for Intel X700 family), and mlx5 (for Mellanox ConnectX-4 and later) NICs. We are spoiled for natively supported 10G, 25G and even some 100G NICs… provided that AppleVT-d works on our hacks. And Chelsio has released a DEXT version of cxgbe for its T5 and T6 lines.

 

Without VT-d, in particular for AMD hacks, we're limited to KEXT drivers, so Chelsio T5 and T6 with the Catalina-era kext and Intel X500 with IntelLucy—which may still be desirable over the native DEXT. 

 

If you can boot with VT-d, DisableIoMapper: false, and no IntelLucy, you may try and benchmark native X550 support. Then add IntelLucy.kext, which should take precedence over com.apple.DriverKit-AppleEthernetIXGBE.dext, and benchmark again.

Then we could look into itlwm.kext; this is where DisableIoMappingMapper could help. And as a last resort, making a custom DMAR; what's the native table?

Sanity check: Does itlwm already supports Tahoe? And have you adjusted your USB map for Tahoe?

That, or the DEBUG version of OpenCore with Misc>Debug>SysReport: true (my favourite, as it works even without successfully booting into macOS).

 

Yea.. quite some time past since my X299 Mojave installation guideline and USB kext creation guideline, but a bunch of things are still valid though. I certainly did not catch yet all the new things since my disappearance from the community in 2019 and my return to Insanselymac a few weeks ago, e.g. that my X550-AT2 NICs should be implemented now natively by macOS. 

 

Everything what you write above sounds like a very good plan. So let's start at first place with trying to make the X550-AT2 NICs run natively. I will consider all your respective suggestions and report back whether or not I succeed with their native implementation.

 

Concerning itlwm.kext: the driver works with Heliport.app, both under Sequoia and Tahoe.

 

In also attach you my USB kexts, both doing also under Tahoe what they should do in principle. For Tahoe I made the proposed change of the kext, without any major improvement in kext performance or functionality.  

 

Last but not least, I attach the dmar.aml, which I extracted in opencore debug mode before implementing the intel AX210 PCIe Bluetooth/WIFI card, as well its modification with SSDTTime. 

 

 KGP-MacPro-ASUS-WSX299S10G-XHCI.kext.zip

 

KGP-MacPro-ASUS-WSX299S10G-XHCI-Tahoe.kext.zip

 

DMAR-original.aml

 

DMAR-modified.aml

 

Here the link to my EFI

 

Many thanks for your help and that you want to guide me through this journey with my X550-AT2 NICs 👍

 

Edit:

 

Test results concerning native implementation of Asus X299 Sage 10G X550-AT2 NICs and itlwm.kext+Heliport functionality of Intel AX210 Bluetooth/WIFI PCIe adapter under Tahoe

 

All results  without any modified dmar.aml or dropped DMAR Table as well as with vt-d enabled in BIOS.

 

1.) No native implementation of X550-AT2 NICs without IntelLucy.kext, SmallTreeIntel8259x.kext and DisableIoMapper and DisableIoMappingMapper disabled (false). System boots though perfectly without both kernel quirks disabled (false). 

 

 

 

Modified SmallTreeIntel8259x.kext works with any combination of DisableIoMapper and DisableIoMappingMapper enabled/disabled but random KPs under Tahoe.

 

 

 

IntelLucy.kext is fully implemented but no LAN/internet with (true) or without (false) DisableIoMapper and DisableIoMappingMapper.

 

 

 

2.) itlwm.kext/Heliport only work with DisableIoMapper enabled (true). DisableIoMappingMapper can be enabled additionally without any difference in performance or functionality. 

 

 

 

Edited June 28, 2025 by KGP-iMacPro

[etorix]

No Ethernet device?

Does the card appear elsewhere? For instance under PCI Devices. Or in Hackintool's device list.

Is it recognised and working if booting another OS, such as a LiveUSB of some Linux distro?

Is the EEPROM still modded?

[kgp]

2 hours ago, etorix said:

As I suspected, the only reserved region is for PCI address 14,00, which should be the USB controller. Removing it may do more harm than good.

 

So, no way to get IntelLucy.kext properly working on my system, not even by adding a modified dmar.aml and dropping the original DMAR table, as there are no other reserved regions than PCI address 14,00, by this you refer to the original DMAR.aml, right?

 

 

 I just add my SmallTreeIntel8259x-KGP-Tahoe.kext, which is somewhat more stable under Tahoe, by modifying the info.plist:

 

1.)
	<key>MinKernel</key>
	<string>25.0.0</string>
2.)
    <key>Transport Segmentation Offload Enabled</key>
    <false/>

Just in case one with similar issues want's to give it a try or knows how to further modify it in order to avoid random KPs under Tahoe. The original SmallTreeIntel8259x.kext works still flawless under Sequoia. 

 

SmallTreeIntel8259x-KGP-Tahoe.kext.zip

 

SmallTreeIntel8259x.kext.zip

Edited June 28, 2025 by KGP-iMacPro

[kgp]

1 hour ago, etorix said:

No Ethernet device?

Does the card appear elsewhere? For instance under PCI Devices. Or in Hackintool's device list.

Is it recognised and working if booting another OS, such as a LiveUSB of some Linux distro?

Is the EEPROM still modded?

which card? the Intel AX210? The card shows up as "Ethernet" under macOS System Settings -> Network. Ethernet 1 is the SmallTreeIntel8259x.kext.

 

 

IOreg:

 

 

Hackintool:

 

 

And yes, all above tests have been performed without any modified DMAR, as I am still not able to properly drop the original DMAR Table with the config.plist under ACPI -> Delete, although I supposedly use the correct values in collaboration with ChatGPT AI and IntelLucy. For the tests above,  I just disabled the DMAR drop under ACPI -> Delete and the modded dmar.aml under ACPI -> Add.

 

Edited June 28, 2025 by KGP-iMacPro

[Mieze]

@KGP-iMacPro Don't rely on ChatGPT because Ai stands for artifical idiocy! Better check the tutorial at https://dortania.github.io/Getting-Started-With-ACPI/Universal/dmar-methods/manual.html#creating-our-customized-dmar-table and understand how to do it properly. If your original DMAR isn't dropped, it's obvious that the config entry is wrong.

[kgp]

8 hours ago, Mieze said:

@KGP-iMacPro Don't rely on ChatGPT because Ai stands for artifical idiocy! Better check the tutorial at https://dortania.github.io/Getting-Started-With-ACPI/Universal/dmar-methods/manual.html#creating-our-customized-dmar-table and understand how to do it properly. If your original DMAR isn't dropped, it's obvious that the config entry is wrong.

@Mieze, thanks for this important advice. I now caught the point. There is only one reserved memory region with Subtable Type : 0001 in my original dmar.aml for the XHCI USB controller with PCI Path 14,0. 

 

 

@etorix says better not to remove it. So I think I cannot do anything in addition to make IntelLucy.kext work on my system. Or is there anything you could improve in particular in your code, likely for a better X550-AT2 compatibility? Is the incompatibility of IntelLucy.kext with my system purely caused by issues with Apple vt-d, which cannot be fixed in your code nor with the 2 kernel quirks or a modified DMAR Table?

Edited June 29, 2025 by KGP-iMacPro

[etorix]

14 hours ago, KGP-iMacPro said:

which card?

Sorry for unclarity. I was inquiring about the Intel X550-AT2 not being displayed and recongnised by drivers.

Your screenshots show vendorID 0x8086, deviceID 0x1563 as expected (see Table 1-2), subsystemID 0x1043 and subsystem vendorID 0x000a which is a mod for SmallTree drivers.

So my best guess, pending comment frrom @Mieze,would be that this prevents correct binding by DriverKit and IntelLucy; I'd suggest to revert the EEPROM to native value, and confine the SmallTree drivers to the dustbin of history.

 

5 hours ago, KGP-iMacPro said:

@etorix says better not to remove it.

i can NOT say with authority not to remove it… but I'd be extremely wary to remove it, as it could cause issues with USB, possibly interfering with the AX210 (it needs a USB port, right?) and/or causing some hard-to-diagnose, non-network related pains elsewhere.

DisableIoMapperg: false, DisableIoMappingMapper: true would be the way to try and deal with it.

[Mieze]

IntelLucy supports X500 chips regardless of the subsystem ID. The subsystem ID is only used to identify cards which support WoL.

[kgp]

2 hours ago, etorix said:

Sorry for unclarity. I was inquiring about the Intel X550-AT2 not being displayed and recongnised by drivers.

Your screenshots show vendorID 0x8086, deviceID 0x1563 as expected (see Table 1-2), subsystemID 0x1043 and subsystem vendorID 0x000a which is a mod for SmallTree drivers.

So my best guess, pending comment frrom @Mieze,would be that this prevents correct binding by DriverKit and IntelLucy; I'd suggest to revert the EEPROM to native value, and confine the SmallTree drivers to the dustbin of history.

 

i can NOT say with authority not to remove it… but I'd be extremely wary to remove it, as it could cause issues with USB, possibly interfering with the AX210 (it needs a USB port, right?) and/or causing some hard-to-diagnose, non-network related pains elsewhere.

DisableIoMapperg: false, DisableIoMappingMapper: true would be the way to try and deal with it.

 

@etorix, just for clarification, we are talking about the X550-AT2 onboard NICs of the Asus Sage X299 10G and not any PCie adapter.

Reverting the EEPROM modding is of major effort (Ubuntu installation etc.) and major impact (I would totally loose access to the SmallTreeIntel8259x.kext implementation, which is so far the only working solution under both, Sequoia and Tahoe). I would give it a try, in case that you are totally convinced that this will allow the native NIC implementation by the DriverKit. @Mieze , already stated above that at least IntelLucy supports X500 chips regardless of the subsystem ID. The open question remaining to me is, why there is just no LAN/internet connection when using IntelLucy.kext with my configuration, although the driver is properly implemented. Ethernet consecutively and successfully connects for a second and immediately falls back to no connection.

 

Yes, the Intel AX210 needs an USB port as also my Broadcom BCM94360CD does. Furthermore I use the BRIO MX and a HyperX Quad Cast 2 on my USB boards, thus I also would tentatively like to avoid any impact on the XHCI controller by the respective DMAR modding.

 

Finally also for clarification: as I already stated above, itlwm.kext/Heliport do not work with DisableIoMapper: false, DisableIoMappingMapper: true.   DisableIoMapper: true is absolutely mandatory at present for itlwm.kext to be implemented during the boot process. DisableIoMappingMapper: true/false has no impact at all… 

 

Having said all this, I do not really know how to proceed now in the best way.