LucyRTL8125Ethernet.kext for Realtek RTL8125

[Mieze]

I just released version 1.2.0 of LucyRTL8125Ethernet, which is identical to 1.2.0d5, and updated the prebuilt binary in the download section.

 

Mieze 🐈‍⬛

[seyd46]

Thank you so much 

[Max.1974]

Thanks @Mieze for update, run a little bit more faster here. 

 

 

Compiled version! Nice!! 

 

 

 

Spoiler

 

Edited October 12, 2024 by Max.1974

[kocoman]

is support for RTL8126 possible? thx

[MaLd0n]

8 minutes ago, kocoman said:

is support for RTL8126 possible? thx

https://www.insanelymac.com/forum/topic/343542-lucyrtl8125ethernetkext-for-realtek-rtl8125/?do=findComment&comment=2821265

 

[Luchina]

Hi @Mieze

 

I have a Z890 Aorus Elite X ICE and it has an onboard RTL8125, however it is not activated with the Kext in any way.

 

I installed another board that comes with two RTL8125 and they start normally but the onboard one still does not start.

 

Below is an example, where the first one is onboard (which doesn't work) and the other two are offboard and work.

 

 

I noticed that the subsystem-id and subsystem-vendor-id are different from the ones that work and so I changed them via DeviceProperties in config.plist but even so the integrated RTL8125 from the motherboard didn't load.

 

 

After reboot:

 

 

But still the onboard RTL8125 doesn't work.

 

 

These two that are active are from the offboard card, the integrated one does not appear and does not work.

 

Is there something to be done via Kext or some other adjustment in the EFI so that it loads and activates the onboard RTL8125?

 

Thanks

 

[LockDown]

hackintool should have at least display it even its not working

[Luchina]

16 minutes ago, LockDown said:

hackintool should have at least display it even its not working

 

It shows the Hackintool PCIe tab, but in the System > Peripherals tab of Hackintool, only when it is enabled/loaded.

[Max.1974]

3 hours ago, Luchina said:

Hi @Mieze

 

I have a Z890 Aorus Elite X ICE and it has an onboard RTL8125, however it is not activated with the Kext in any way.

 

I installed another board that comes with two RTL8125 and they start normally but the onboard one still does not start.

 

Below is an example, where the first one is onboard (which doesn't work) and the other two are offboard and work.

 

 

I noticed that the subsystem-id and subsystem-vendor-id are different from the ones that work and so I changed them via DeviceProperties in config.plist but even so the integrated RTL8125 from the motherboard didn't load.

 

 

After reboot:

 

 

 

HI @Luchina i have the same Device and works fine after compile the Kext. 

 

You have 3 entries with error from ACPI drop table. Need fix it to run en0 and just once device. 

 

Update your pci.ids and usb.ids inside Hackintool.

 

Need replace files: 

 

https://pci-ids.ucw.cz

 

http://www.linux-usb.org/usb-ids.html

 

Source: how-to-update-pci-ids-and-usb-ids-on-hackintool/

 

My working compiled Kext

 

LucyRTL8125Ethernet.kext.zip

 

 

 

My Device is almost the same as your 

 

 

 

Edited November 22, 2024 by Max.1974

[Luchina]

12 hours ago, Max.1974 said:

 

HI @Luchina i have the same Device and works fine after compile the Kext. 

 

You have 3 entries with error from ACPI drop table. Need fix it to run en0 and just once device. 

 

Update your pci.ids and usb.ids inside Hackintool.

 

Need replace files: 

 

https://pci-ids.ucw.cz

 

http://www.linux-usb.org/usb-ids.html

 

Source: how-to-update-pci-ids-and-usb-ids-on-hackintool/

 

My working compiled Kext

 

LucyRTL8125Ethernet.kext.zip 59.66 kB · 2 downloads

 

 

 

My Device is almost the same as your 

 

 

 

 

Hi @Max.1974, don't work.

 

I have other 2 setups with same RTL8125, identical (device-id, vendor-id, subsystem-id and subsystem-device-id) and work normally.

 

The problem only occurs with the onboard RTL8125 of the Z890 Aorus Elite X ICE motherboard.

 

Anyway, thanks for the help.

[Mieze]

Realtek NICs are special in a way that the different versions of the chip aren't distinguishable by the PCI dev ID. They all share the same dev ID and the driver has to read a certain configuration register to identify the revision (RTL8125A, RTL8125B, etc.). I'm afraid, but I think that your board might have a new revision of the NIC which is still unsupported by the driver so that I'll have to update it. As already explained above, this isn't an easy task as it requires almost 50% of the code to be rewritten. I'm currently thinking about how to do it the best way.

[Luchina]

7 minutes ago, Mieze said:

Realtek NICs are special in a way that the different versions of the chip aren't distinguishable by the PCI dev ID. They all share the same dev ID and the driver has to read a certain configuration register to identify the revision (RTL8125A, RTL8125B, etc.). I'm afraid, but I think that your board might have a new revision of the NIC which is still unsupported by the driver so that I'll have to update it. As already explained above, this isn't an easy task as it requires almost 50% of the code to be rewritten. I'm currently thinking about how to do it the best way.

 

Hi @Mieze,

 

I understand, I had even read above about the RTL8126, which I understand is a new board, just like the I225 and the new I226... Since mine "continues to be" an RTL8125, I imagined that it could be some other adjustment or something less tragic to deal with!

 

Thank you very much!

[turai]

The chip on the Gigabyte X870 GAMING WIFI6 is also one of the newer versions. Reports itself as revision 0x0c on Linux, kext loads properly but the interface never shows up.

[Mieze]

Here is version 1.2.1d0 of LucyRTL8125Ethernet which implements some important changes:

• Fixes an issue with AppleVTD.
• Eliminates a memory leak when trying to unload the driver.
• Improves performance in situations when kernel memory becomes scarce.

Please keep in mind that this is a development version. Mostly users with MSI boards may benefit form the changes because the weird memory layout of these boards seems to produce situations in which the network stack is unable to provide network buffers according to the driver's demand so that packets must be dropped. The new version keeps some spare buffers at hand to better handle such situations. According to my tests Gigabyte boards aren't affected by this issue.

 

Good luck testing❣️

 

Mieze 😽

LucyRTL8125Ethernet-V1.2.1d0.zip

[Mieze]

I uploaded version 1.2.2 a few minutes ago to fix the IOFree() bug in 1.2.1 which may cause a KP when trying to unload the driver (usually doesn't happen in normal lifecycle). Everybody is encouraged to upgrade.

 

Mieze 😽

[seyd46]

thank you very much, cats miou

[Alpha22]

thanks for the update

[xtddd]

thank you very much

[Ginger Geek]

THANKS! 

Edited October 9, 2025 by Ginger Geek

[Ginger Geek]

I need to force wake on LAN for this PCIe card as my onboard does wake on lan but the add in pcie card will not. If I edit the ternary in in this function will it force WoL to work?? Im a node.js dev and a little embedded c++ so I have a limited understanding but I will try to look through this and figure out what is gong on but I honestly I'm not in my comfort zone here. 

IOReturn LucyRTL8125::setWakeOnMagicPacket(bool active)
{
    IOReturn result = kIOReturnUnsupported;

    DebugLog("setWakeOnMagicPacket() ===>\n");

    if (wolCapable) {
        linuxData.wol_enabled = active ? WOL_ENABLED : WOL_DISABLED;
        wolActive = active;
        
        DebugLog("WakeOnMagicPacket %s.\n", active ? "enabled" : "disabled");

        result = kIOReturnSuccess;
    }
    
    DebugLog("setWakeOnMagicPacket() <===\n");

    return result;
}

 

[Mieze]

@Ginger Geek First of all, you are on the wrong track because macOS doesn't support WoL from S5. WoL is supported only from S3. Second, WoL from S5 usually only works from onboard NICs. Many mainboards are unable to wake up from S5 using WoL using an add-in card. These are the reasons why I have decided not to implement WoL from S5 at all. Another argument against it is the fact that the system might not be able to stay in S5 in case that things go wrong.

 

If you want to implement it, you are on your own. Keep in mind that setWakeOnMagicPacket() is only called when the system is going to sleep, but not when shutdown or restart is requested. Instead of that, systemWillShutdown() is called for reboot/shutdown. That's the place where you'll have to add the missing code to enable WoL. Please see the source code of IntelMausiEthernet for an example how it can be done.

 

Mieze 😺

Edited October 9, 2025 by Mieze

[xenophon]

Re WOL with Mieze's RTL8125 driver, let me offer two data points:

 

1) PCIe RTL8125 cards

My TP-Link RTL8125 appears as folllows in Hackintool PCI list:

06:00.0 10EC 8125 10EC 8125 Disabl Realtek Semiconductor Co., Ltd RTL8125 2.5GbE Controller  Network controller   Ethernet controller  P21@1B,4/PXSX@0 ethernet  PciRoot(0x0)/Pci(0x1B,0x4)/Pci(0x0,0x0) 

 

Runs on the latest LucyRTL8125Ethernet, and wakes-on-LAN beautifully. For the sake of completeness, this is under Sequoia, with AppleVTD enabled (DisableIoMapper NO, DisableIoMapperMapping YES).

 

I got the PCIe card because I had sporadic kernel panics with IntelMausi on the Designare Z390 mobo's internal en, and never managed to resolve the issue.

 

2) Built-in

On an ASUS TUF B660, again running LucyRTL8125Ethernet but this time under Tahoe 26.0.1, WOL functionality is present, however for the system to wake from deep sleep, one has to enable "Power-ON from PCI-E" in the BIOS (defaults to Disabled).

 

BTW, in this case, the driver does NOT work with AppleVTD enabled and requires DisableIoMapper to be set to YES.

 

Hope this helps.

 

Xen

Edited October 10, 2025 by xenophon

[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]

In case you are running Tahoe on your hackintosh but want to enable AppleVTD, you might want to try RTL812xLucy.kext, my latest project which is a fully AppleVTD compatible replacement for LucyRTL8125Ethernet. RTL812xLucy also comes with support for new hardware, like the RTL8125BP, RTL8125CP and RTL8125D. Since version 1.0.1 RTL812xLucy offers full jumbo frame support up to 9000 bytes MTU. Good luck testing!

 

Mieze 😺

[Mieze]

Although I was planning to give up LucyRTL8125Ethernet in favour of RTL812xLucy, I decided to update LucyRTL8125Ethernet because of a problem with RTL812xLucy. Due to a weakness in the underlying Linux source code, RTL812xLucy is unable to perform tx operations with line speed when using TSO (TCP Segmentation Offload), which results in a 15% drop in tx speed with TSO enabled. This doesn't happen with TSO disabled, but without TSO CPU load will be higher when sending large amounts of data. Attached you'll find version 1.2.3 (build 1.2.300) of LucyRTL8125Ethernet as an interim solution for those of you, who need to run Tahoe with AppleVTD enabled. The improvements include much of the features of RTL812xLucy:

• AppleVTD support with Tahoe
• Full jumbo frame support up to MTU 9000.
• Fixes a Kernel Panic which may occur when using TSO in combination with VLAN tagged packets.

For the future I'm planning to rebase RTL812xLucy on the Linux sources which have been used for LucyRTL8125Ethernet. Until the TSO related issue of RTL812xLucy will be solved, I recommend users with one of these chips to continue using LucyRTL8125Ethernet:

• RTL8125A
• RTL8125B

Users with the following chips, which are unsupported by LucyRTL8125Ethernet, have to use RTL812xLucy with TSO disabled:

• RTL8125BP
• RTL8125CP
• RTL8125D

Mieze 😺

LucyRTL8125Ethernet-1.2.300.zip

Edited February 24 by Mieze
Fixed incomplete sentence