IntelLucy for the Intel X500 family

[etorix]

So it was a configuration issue with VT-d after all. Since @Mieze designed IntelLucy to take precedence you shouldn't even need DisableIOMapper to use the kext over the native dext.

[kgp]

@Mieze, @etorix none of your suppositions has been the case. I found the culprit, and now also my EFI works with DisableIOMapper= false and either DEXT DriverKit or IntelLucy. 

 

The culprit was the com.apple.iokit.IOSkywalkFamily replacement for the OCLP-WIFI patch.

 

If I disable 

 

and disable 

 

 

both DEXT DriverKit and IntelLucy work as expected without any other changes in my EFI-Folder. I am done 👍

 

 

Edited October 6, 2025 by KGP-iMacPro

[kgp]

@Mieze, could you please do me a favour and check IntelLucy connectivity with your X550-AT2 and MiktroTik switch under macOS Tahoe 26.0.1 (25A362) on your particular system? Following issue. I am writing you using the DEXT DriverKit. 

Edited October 11, 2025 by KGP-iMacPro

[Mieze]

@KGP-iMacPro I installed Tahoe on my test machine (the MSI board from my signature) and can conform that it works, but I had to disable AppleVTD to make it work. This machine has several reserved memory region in it's DMAR but used to work fine under Sequoia. As already mentioned several times before, it looks like Apple changed the kernel memory layout, which seems to trigger the issue.

 

Mieze 😺

Edited October 11, 2025 by Mieze

[kgp]

24 minutes ago, Mieze said:

@KGP-iMacPro I installed Tahoe on my test machine (the MSI board from my signature) and can conform that it works, but I had to disable AppleVTD to make it work. This machine has several reserved memory region in it's DMAR but used to work fine under Sequoia. As already mentioned several times before, it looks like Apple changed the kernel memory layout, which seems to trigger the issue.

 

Mieze 😺

 

@Mieze, many thanks for testing and confirming that IntelLucy only works with disabled AppleVTD under Tahoe 26.0.1. For me, IntelLucy perfectly worked with AppleVTD enabled under Tahoe 26.0. The interesting thing is that Apple´s DEXT DriverKIT continues successfully working with AppleVTD enabled under Tahoe 26.0.1, thus I almost  exclude any AppleVTD issue, just in case that you might want to further investigate a possible issue of IntelLucy with Tahoe 26.0.1

 

Have a great day,

 

KGP 👍

 

Edited October 11, 2025 by KGP-iMacPro

[Mieze]

@KGP-iMacPro Just to clarify, I used 26.0, not 26.0.1, for my test. The difference between IntelLucy and the dext driver is that IntelLucy runs inside the kernel, whereas dext drivers run outside the kernel in a separate space. This makes there next driver independent of the kernel memory layout but comes with a performance penalty and prevents it from using jumbo frames.

 

Mieze 😺

Edited October 11, 2025 by Mieze

[meg2014]

Quote

@KGP-iMacPro:

 

So you have been discussing this DEXT driver for a while and I looked for the driver and can't find it.  Can you post it?  Is it just a DMG file or is it more complex than that?

 

I'm curious to see how it works.  I did look at the German forum link that you posted but it just timed out on me.

Edited October 11, 2025 by meg2014

[kgp]

11 hours ago, meg2014 said:

 

So you have been discussing this DEXT driver for a while and I looked for the driver and can't find it.  Can you post it?  Is it just a DMG file or is it more complex than that?

 

I'm curious to see how it works.  I did look at the German forum link that you posted but it just timed out on me.

 

it is Apple's native ethernet driver: /System/Library/DriverExtensions/com.apple.DriverKit-AppleEthernetIXGBE.dext. If everything is fine with VTD/IOMMU on your system, it should inject automatically as soon you disable IntelLucy. btw... you might also find com.apple.DriverKit-AppleBCMWLAN.dext there, which I suppose is used by the BCMC patch.  

Edited October 12, 2025 by KGP-iMacPro

[kgp]

10 hours ago, Mieze said:

@KGP-iMacPro I installed Tahoe on my test machine (the MSI board from my signature) and can conform that it works, but I had to disable AppleVTD to make it work. This machine has several reserved memory region in it's DMAR but used to work fine under Sequoia. As already mentioned several times before, it looks like Apple changed the kernel memory layout, which seems to trigger the issue.

 

Mieze 😺

 

Please remember that the only reserved memory region in my DMAR is the XHCI controller. Thus, I guess there is nothing I can do from my side.  

[meg2014]

21 hours ago, KGP-iMacPro said:

 

it is Apple's native ethernet driver: /System/Library/DriverExtensions/com.apple.DriverKit-AppleEthernetIXGBE.dext. If everything is fine with VTD/IOMMU on your system, it should inject automatically as soon you disable IntelLucy. btw... you might also find com.apple.DriverKit-AppleBCMWLAN.dext there, which I suppose is used by the BCMC patch.  

 

Thanks.  Tried it and this driver does allow me to add BCMC to my config without KPs and Wifi is working without my 10G card bouncing.  Overall pretty stable so far.  My switch allows me to set an MTU globally, so I set it to 9000 and speed, after that, was really good.  Nice.

Edited October 12, 2025 by meg2014

[Mieze]

15 minutes ago, meg2014 said:

My switch allows me to set an MTU globally, so I set it to 9000 and speed, after that, was really good.

Looks like you don't understand the concept of the MTU? The DEXT driver doesn't support jumbo frames by design and is limiting the maximum MTU to 2034, no matter what the settings of your switch are. IP path MTU discovery will reduce the real MTU to that value.

 

Mieze 😺

Edited October 12, 2025 by Mieze

[kgp]

25 minutes ago, Mieze said:

Looks like you don't understand the concept of the MTU? The DEXT driver doesn't support jumbo frames by design and is limiting the maximum MTU to 2034, no matter what the settings of your switch are. IP path MTU discovery will reduce the real MTU to that value.

 

Mieze 😺

 

Having now the MikroTik switch with all SFP+ RJ45 transceivers, I would really love to get IntelLucy work again with AppleVTD under Tahoe 26.0.1 anyway, not only because of the advantage of Jumbo Frames... 😉 

Edited October 12, 2025 by KGP-iMacPro

[Mieze]

@KGP-iMacPro Provided you don't need Thunderbolt or are using a Notebook so that Wifi is the only networking option for you, I see no reason why anybody wants to use AppleVTD. In case it works with the vanilla DMAR and the machine is working stable, there is no need to disable it but patching the DMAR itself is dangerous and comes with the risk of kernel panics or sudden reboots. Besides that, AppleVTD may break with the next update because of a changed kernel memory layout. The Gigabyte Z490 Gaming X is such a board. Before 15.5 AppleVTD seemed to work stable with a patched DMAR, but  under load (e.g. using Xcode) the machine rebooted suddenly, even with the DEXT driver. With 15.5 up to 15.7.1 the reboots disappeared and AppleVTD worked properly but with Tahoe that's over. My conclusion is that using AppleVTD with a patched DMAR is a stability risk. Therefore I leave it disabled if such dangerous operations are required to make it work. Patching the DMAR is a last resort if there is absolutely no other way.

 

Unfortunately, AppleVTD isn't open source so that we can't find out what is really going on with a reasonable amount of work.

 

Mieze 😺

Edited October 12, 2025 by Mieze

[kgp]

@Mieze, well I use Thunderbolt with a flashed GB Titan Ridge controller (which however is also working somehow without AppleVTD), but the main reason for the need of AppleVTD for many people would be BCMC, in case this new patch would reach overall stability and would provide all continuity features (including Airdrop) in the near future. However, I fully understand that it sounds like a mission impossible to keep IntelLucy compatible with AppleVTD with each update of macOS.

 

Like always, many thanks for sharing your expertise. I really learned a bunch of things here in this thread and I am very grateful for all this information and knowledge.

 

KGP 💫 

[meg2014]

4 hours ago, Mieze said:

Looks like you don't understand the concept of the MTU? The DEXT driver doesn't support jumbo frames by design and is limiting the maximum MTU to 2034, no matter what the settings of your switch are. IP path MTU discovery will reduce the real MTU to that value.

 

Mieze 😺

I worked as a Cisco certified Network Engineer for over 15 years, so I do understand the concept of MTU.  You really might want to keep in mind that my system is not just Macs, there are other operating systems on this machine and they don't have that limitation of the Apple DEXT driver.   

 

By the way, I didn't work on the little routers, I worked on the big ones, on BGP as a team lead at ATT.

Edited October 13, 2025 by meg2014

[Mieze]

@meg2014 As a network engineer you should know that the MTU is enforced by hardware. It is programmed in the NIC's receiver, so that any packet exceeding the maximum length is considered to be a faulty packet and discarded. This is when path MTU discovery steps in and reduces the packet size for the communication to a value which is supported by any station involved with the communication.

 

Mieze 😺

[meg2014]

4 hours ago, Mieze said:

@meg2014 As a network engineer you should know that the MTU is enforced by hardware. It is programmed in the NIC's receiver, so that any packet exceeding the maximum length is considered to be a faulty packet and discarded. This is when path MTU discovery steps in and reduces the packet size for the communication to a value which is supported by any station involved with the communication.

 

Mieze 😺

 

Well, this has been fun.  But I'm out.  See you around sometime.

Edited October 13, 2025 by meg2014

[Mieze]

I tested the driver with Tahoe during the last days and can confirm that it works with 26.0 and 26.0.1, but AppleVTD support is broken. Unfortunately there is no easy solution for this problem, so that you'll have to keep AppleVTD disabled while using the driver with Tahoe. I hope to get more information once the source code of Tahoe is out. My investigation of the problem indicates that DMA buffer mapping by the IOMMU has to be reworked, which isn't an easy task and might require some to time to find a convenient solution.

 

Mieze

[Mieze]

@KGP-iMacPro I've been busy investigating the AppleVTD issue over the weekend and was able to find out why the driver doesn't work with AppleVTD enabled anymore under Tahoe. The NIC needs to access two areas in RAM. A small area called the descriptor rings, which are used to exchange information about commands and buffers between CPU and NIC. This area is properly mapped by IntelLucy itself and access to the descriptors is still working as designed with AppleVTD. The other area the packet buffers, which are under control of the kernel and used to be mapped by the kernel itself before Tahoe. With Tahoe this behaviour seems to have changed. It looks like the kernel doesn't map the packet buffers anymore, so that the NIC isn't able to access the packet buffers. As a result, there is no useful data going out and receive buffers are empty, although the descriptors indicate that the rx and tx buffers have been processed properly.

 

I've been studying the kernel source code of macOS 15.6 during the last days to get a better understand how packet buffers are handled. As receive buffers are allocated by the driver, it would be possible for a driver to create its own puffer pool and map the buffers to solve the problem. Actually, this is what the IOSkywalk driver architecture does and it should be possible to create a similar solution with the traditional network driver architecture. For transmit buffer the situation is much more complex. They are created by the network stack and handed over to driver for transmission, which means that they are scattered all over the kernel memory space making it almost impossible for the driver to map each buffer. Traditional Apple driver's like the AppleBCM5701Ethernet.kext and AppleEthernetAquantiaAqtion.kext solve this problem in a very inefficient way. They create a mapped output buffer ring and copy all outgoing packets into the ring. At the moment it looks like this is the only reliable solution with the traditional driver interface.

 

I hope to get more insight once the source code of Tahoe will be available. What makes me wonder is the fact that you reported that IntelLucy used to work with AppleVTD enabled under 26.0, but stopped working after the update to 26.0.1, because on my test machine this already happened with 26.0. If there was a major change in the behaviour of the kernel with traditional network drivers, one would expect that to happen in 26.0. That's why I'm asking if IntelLucy was really working under 26.0 with AppleVTD?

 

Mieze 😺

[kgp]

@Mieze, initially, I tested IntelLucy and the DEXT driver alternately under macOS 26.0 and Sequoia 15.7 with AppleVTD enabled. Both seemed to initialize properly. The MikroTik switch showed a stable green link, and System Settings reported a valid IP. I even enabled Jumbo Frames with IntelLucy.

 

After updating to 26.0.1 while still using the DEXT driver, I continued testing DEXT with BCMC. For a cross-check, I switched to BCMC and IntelLucy. Then I noticed that Internet connectivity came from BCMC, while the Ethernet interface only showed a self-assigned IP, even though the MikroTik switch still showed a stable green link.

 

Finally, I removed everything related to BCMC, including the hardware. IntelLucy still did not work with AppleVTD under 26.0.1.

 

I might have mixed something up during all these tests — IntelLucy without AppleVTD, DEXT driver with AppleVTD, IntelLucy with AppleVTD, and both with AppleVTD plus BCMC — and on top of that, I was running tests simultaneously under Sequoia and Tahoe. So it’s entirely possible that I overlooked or confused something along the way.

 

Only a clean install of 26.0 on a test drive could confirm whether IntelLucy really works with AppleVTD under 26.0 on my system. I hope nothing crucial in my EFI folder has changed in the meantime, but I don’t think so, as IntelLucy continues working with AppleVTD under Sequoia 15.7.  I plan to perform this test later today and will report back with the results.

Edited October 20, 2025 by KGP-iMacPro

[kgp]

@Mieze, the test was negative. No Ethernet connection with IntelLucy under macOS 26.0 with AppleVTD enabled.   

[cfmwan]

On 10/21/2025 at 3:37 AM, KGP-iMacPro said:

@Mieze, the test was negative. No Ethernet connection with IntelLucy under macOS 26.0 with AppleVTD enabled.   

Are you the motherboard of ASUS? My ROG STRIX Z690-E GAMING Wi-Fi is also VT-D. I can't use Intel X520-DA1 PCIe when I open it. I can only use SonnetEthernet-10GE, but I can't show the speed.

[kgp]

6 hours ago, cfmwan said:

Are you the motherboard of ASUS? My ROG STRIX Z690-E GAMING Wi-Fi is also VT-D. I can't use Intel X520-DA1 PCIe when I open it. I can only use SonnetEthernet-10GE, but I can't show the speed.

 

Everything as discussed in the postings above. Happy reading 👍

[Mieze]

I just wanted to let you know that I fixed the problem with AppleVTD under Tahoe. Last night I successfully tested IntelLucy with AppleVTD enabled under 26.0.1 and 26.1. It's still not ready to be published, because the changes are complex and I have to run more tests. Also there are still few minor glitches, which need to be fixed , but at least I can promise that there will be AppleVTD compatible versions of all my actively maintained drivers in the near future.

 

Mieze 😺

[kgp]

2 hours ago, Mieze said:

I just wanted to let you know that I fixed the problem with AppleVTD under Tahoe. Last night I successfully tested IntelLucy with AppleVTD enabled under 26.0.1 and 26.1. It's still not ready to be published, because the changes are complex and I have to run more tests. Also there are still few minor glitches, which need to be fixed , but at least I can promise that there will be AppleVTD compatible versions of all my actively maintained drivers in the near future.

 

Mieze 😺

 

@Mieze, you are simply the best! I was convinced that you will find soon a solution!   💯💥💫. Eager to receive the update soon, and until then.. happy testing 👍

Edited November 5, 2025 by KGP-iMacPro