New Driver for Realtek RTL8111

[macattackjack]

Please report back with your kernel logs, an IOReg dump (use version 2.1 of IORegExplorer because later versions produce corrupted output files) and the output of "ifconfig -a -v" as well as "kextstat".

 

By the way: Which version of the driver do you use?

 

Mieze

Hi

 

I have attached the regular dump and a "-a -v" dump. I don't have an ifconfig file, or don't know how to do that, since I've never done this before.

 

The version of the driver is the 1.3. I tried it with the development 6 driver with the same result.

 

When booting with -a -v, it's saying something like tx lost, interrupt lost?

 

I don't know how to do the kextstat or ifconfig you've asked for.

 

Also, this is essentially a vanilla build. No ssdt file, and only kexts to make it functional. Modded AppleIntelCPUPowerManagement.kext, fakesmc GenericUSBXHCI and a VoodooHDA.kext. and the realtek 2.06 driver. I do this because it allows me to boot from different MBs and CPUs.

 

I've spend a few days trying various drivers in various combinations, with no luck. I've been doing builds since 10.5 with P4 cpus, so I have some experience with all of this.

 

I will also say, this is the only driver that shows both network card in verbose boot and in the control panel.

 

Thanks!

 

 

Rackintosh RegDump.zip

[Mieze]

First, you MUST remove any other Realtek driver from your system because Realtek's NICs are quite strange in the way you have to identify individual members of the RTL8111 family: you need to read the transmitter configuration register which is a R/W register and gets modified by the driver's initialization code. Once another driver has touched the register my driver will be unable to identify the chip correctly. I also recommend to disable the UEFI network stack and network boot in the UEFI setup. Don't forget to recreate the kernel cache after removing a kext.

 

Second, use Terminal to get the information I asked for and type the following 3 commands:

ifconfig -a -v

kextstat

grep kernel /var/log/system.log 

Mieze

[macattackjack]

Hi

 

I use kext wizard to install the kexts, and don't use the kextcache on boot.

 

First I completely removed the IONetworkingFamily.kext, and only installed new 8111e kext. The OS didn't see the network at all. Then I reinstalled the IOnetworkingFamily.kext without any other networking chip kexts, and the OS sees both chips, and will, after alternating back and forth between  no cable and no address status, connect with the card connected to the internet (which is what I'm using now to post this message) The second card however keeps alternating back and forth. Also everytime I reboot, it seems the chip has to renegotiate the connection and goes through the same alternations until it grabs the connection. Perhaps this is normal?

 

As far as the bios, I had already disabled any network rom, but there is no way to disable the UEFI driver in the bios. I've looked around and can't find any workarounds for it either.

 

Thanks

 

Rackintosh RegDump 04-03-2014 5 pm.zip

[Mieze]

Hi

 

I use kext wizard to install the kexts, and don't use the kextcache on boot.

 

First I completely removed the IONetworkingFamily.kext, and only installed new 8111e kext. The OS didn't see the network at all. Then I reinstalled the IOnetworkingFamily.kext without any other networking chip kexts, and the OS sees both chips, and will, after alternating back and forth between  no cable and no address status, connect with the card connected to the internet (which is what I'm using now to post this message) The second card however keeps alternating back and forth. Also everytime I reboot, it seems the chip has to renegotiate the connection and goes through the same alternations until it grabs the connection. Perhaps this is normal?

 

 

 

 

This could be a bad cable, an incompatibility with the switch or a firmware issue causing trouble with auto negotiation. It might help to set the speed manually or try to exchange some component (cable, switch, etc.).

Apr  3 16:56:33 localhost kernel[0]: unknown chip version (7c800000)

Take a look at this line. As the code which detects the chip is from Realtek's linux driver and they probably know their NICs best, this is the issue I described in the last post. Something is writing to the tx config register making it impossible to correctly detect the NIC model. Please check again if there is really no other Realtek driver in /S/L/E. This is the only chance we have provided this also happens with the latest development version (1.2.0) I posted some time ago because older Versions don't support the latest members of the RTL8111 family.

 

By the way, which of the NICs is working? The onboard or the add-in card?

 

Mieze

[Onixs]

Hi Mieze
If you can recall, i myself had that same issue with the "unknown chip"

Hello Mieze

I have Gigabyte GA-945GCM-S2L with RTL8111C chip.

Ethernet [RealtekRTL8111]: EEE support enabled.
Ethernet [RealtekRTL8111]:TCP/IPv4 segmentation offload enabled.
Ethernet [RealtekRTL8111]:TCP/IPv6 checksum offload enabled.
Ethernet [RealtekRTL8111]: Using interrupt mitigate value 0x5f51.
unknown chip version (7c800000)
Ethernet [RealtekRTL8111]: RTL8168B/8111B: (Chipset 0) at 0x2e8d1000, ff:ff:ff:ff:ff:ff

More logs...

Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]:Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]:Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
RealtekRTL8111: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]:Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]:Link up on en0, 1-Gigabit, Full-duplex, flow-control
Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Ethernet [RealtekRTL8111]:Link up on en0, 1-Gigabit, Full-duplex, flow-control 

Im currently using Realtek original driver, but hoping that your driver will support this.

iirc, i managed to fix itby removing other realtek kext and removed /L/P/network plist
imo, network plist contains assigned address and mac address by other realtek drivers which might conflict with yours, so removing it resolved mine.

[macattackjack]

Rals2007, I just tried deleting the network plist, with the same result.

 

Mieze, I've tried setting the card manually, but it's constantly trying to renegotiate, and I can't enter the settings into it.

 

As far as a cables, and the computer is part of a working system, and I've checked the cables.

 

I've also called MSI to see if there's a work around for the UEFI driver in the bios. They have to call me back.... 

 

The only other networking kext I know of is the IONetworkingFamily. I've removed all the other drivers in the package, but removing it completely causes the Pref pane to freeze in the system control panel. I've attached it here if that will help.. 

 

IONetworkingFamily altered.zip

[Mieze]

Mieze, I've tried setting the card manually, but it's constantly trying to renegotiate, and I can't enter the settings into it.

 

I've also called MSI to see if there's a work around for the UEFI driver in the bios. They have to call me back.... 

 

The only other networking kext I know of is the IONetworkingFamily. I've removed all the other drivers in the package. Removing it completely causes the Pref pane to freeze in the system control panel. I've attached it here if that will help.. 

 

 

The vanilla IONetworking.kext is vital for the network system and must not be removed. Just keep it!

 

Maybe I can find a solution? Are you able to build from source? It would make testing easier.

 

Mieze

 

PS: Please try the attached kext which is slightly modified.

bool RTL8111::initRTL8111()
{
    struct rtl8168_private *tp = &linuxData;
    UInt32 i;
    UInt16 mac_addr[4];
    bool result = false;
    
    /* Try to clear bits which might affect chip recognition. */
    WriteReg32(TxConfig, ReadReg32(TxConfig) & ~0x7CF00000);
    
    /* Identify chip attached to board */
	rtl8168_get_mac_version(tp, baseAddr);
    
    /* Assume original RTL-8168 in case of unkown chipset. */
    tp->chipset = (tp->mcfg <= CFG_METHOD_27) ? tp->mcfg : CFG_METHOD_1;

RealtekRTL8111.kext.zip

Edited April 4, 2014 by Mieze

[Onixs]

Mieze

 

Im not really coder, but trying to be lol...

This is your original code. Based on your modified one above, should Add 2 liners, remove some line, and change 24 to 27?

 

bool RTL8111::initRTL8111()

{

    struct rtl8168_private *tp = &linuxData;

    UInt32 i;

    UInt16 mac_addr[4];

    bool result = false;

 

/* Try to clear bits which might affect chip recognition. */                <--- Add this 2 lines?
WriteReg32(TxConfig, ReadReg32(TxConfig) & ~0x7CF00000);

        

    /* Identify chip attached to board */

rtl8168_get_mac_version(tp, baseAddr);

    rtl8168_print_mac_version(tp); <---- remove line?

    

    /* Assume original RTL-8168 in case of unkown chipset. */

    tp->chipset = (tp->mcfg <= CFG_METHOD_24) ? tp->mcfg : CFG_METHOD_1; <--- change 24 to 27?

As you know, i already fixed my issue. but just trying to understand what macattackjack issue is

 

Thanks

[Mieze]

@rals2007: Well, this is experimental code. I'm not sure if it will work for everybody, but I think it's worth a try. Let's see if it helps him. In case of success I will integrate it into the driver and ask the community to test it but as of now, it's only meant for him.

 

The patched version is based on the 1.2.0 development-6 code. The only line that's new is:

    /* Try to clear bits which might affect chip recognition. */
    WriteReg32(TxConfig, ReadReg32(TxConfig) & ~0x7CF00000);

Mieze

[Onixs]

Did that and compiled, now the issue im having before with GA-945GCM-S2L with RTL8111C chip if realtek's driver is installed is gone . This is just an isolated issue for me though. will just wait for others.

Again, Thanks!

[Mieze]

@macattackjack: Any results with the patched version I posted?

 

Mieze

[macattackjack]

Hi Mieze

 

The short answer is, the UEFI driver of the new bios is the problem. Again, I updated the bios in order to use the new 4930k cpu. I'm still using the 3820 for the these tests.

 

The advantage of the MSI board is it has two Bios on it with a switch to go back and forth between each.

 

I was loading and unloading so many different kexts I was getting confused and couldn't say for sure what was causing what, so I installed the bios 7735v1.6 onto the other bios, and reinstalled the networking kexts from my known working system. Both interfaces started working again as they had before. I then loaded version 1.3 of the 8111e kext with the 7735v1.6 bios, and both networks continued to work. I then switched the bios back to the 7735v2.7 bios and rebooted and am getting the same fluctuation between connected and disconnected on the internal network.

 

I am going to try:

1. removing the pci-e network card, and see what happens.

2. Try the kext you modified Mieze.

 

Thanks again.

 

I am going to try

[Mieze]

Attached to this post you will find the release candidate of version 1.2.0. As always the archive includes binaries and source code. There are 2 important changes since the last development built:

1. I reworked the chipset identification code in order to cope with situations where identification failed because other drivers have modified TxConfig before.
2. The driver now uses a different interrupt mitigate value (always 0x5f51) for 10 and 100 MBit connections making network access more responsive. Interrupt mitigate for gigabit connections is unchanged because the traditional interrupt mitigate value is already optimized for gigabit ethernet.

Therefore I would like to ask you to test the driver thoroughly on your system. Provided there are no serious bug reports, I will make this release candidate the final version 1.2.0. 

 

Good luck!

 

Mieze

 

Edit: As some users reported that RC1 introduced a new bug with chip recognition, I decided to remove the archive and recommend to use RC2 as a replacement. It can be found here: http://www.insanelymac.com/forum/topic/287161-new-driver-for-realtek-rtl8111/?p=2010669

Edited April 7, 2014 by Mieze

[Mieze]

@macattackjack: please use the release candidate because it already includes the patch I described.

[macattackjack]

Hi Meize

 

I tried the new driver, and it's still doing the same thing. I can see the changes you made in what the OS is reporting in verbose mode.

 

I wanted to make sure it wasn't a problem with the internal chip itself, so I then used the same drive with a x79ma-gd45 mb and 4970k cpu, but after some experimenting, I go it to boot with the different MB and it still had the same result.

 

All I can say for sure is it's the new bios and UEFI stuff that's messing it up. I'm afraid I can't provide much more by way of troubleshooting. As much as I'd like to get the internal network to work properly, I am starting to think perhaps the 15 dollars for another PCI-E network card might be worth it. (assuming of course the problem is with the internal card, and not because it's trying to read two separate cards.

 

Right now I can only get the os to boot with the cpus=1 flag, and I forget what I did with the 4970 to get it to work correctly. I've got to solve that problem again and then work on the network again. I'll let you know what happens.

 

Either way, thanks for your help with all of this!

[macattackjack]

Update

 

I managed to get the system booting properly with the 4930K and X70MA-GD45 board with 10.8.4.

 

I've found another 8111E NIC kext and tried it, and it's doing the same thing alternating back and forth between connected and disconnected.

 

I installed the v2.0.6 kext from realtek and installed a second pci-e NIC card and both work correctly.

 

My guess: without an actual MSI board to work from, it's going to be hard to get this to work. The kexts and install I used are from http://rampagedev.wordpress.com/dsdt-downloads/msi-x79/ and the NIC kext from there doesn't work correctly. The driver I'm using now is the same one I have been useing, v2.0.6 from realtek but it's only for 10.7 and they have yet to update it. The Realtek driver does not see the internal NIC like yours does.

 

This is not ideal. Any other thoughts?

[Mieze]

@macattackjack: Well, don't expect any update from Realtek. That's why I started my project. I don't know what exactly is wrong with the UEFI driver for this board but it's up to MSI to fix that problem. By the way this issue will also affect linux on this board. I have got an MSI B75MA-P45 using latest UEFI which works fine so that there is hope that they will solve the problem soon.

 

For the near future I think it's best to disable the onboard NIC and use a second add-on card. Also check the boot flags usually the only argument that is needed to boot >=10.8 is "slide=0". In particular using npci=0x2000 or npci=0x3000 might cause trouble with drivers. Fixing the DSDT helps to get a stable system too.

 

Mieze

[macattackjack]

Meize

 

I'm waiting for a call from MSI about this system. I called tech support and they're supposed to call me back about this.

 

I went today and got the second PCI-E card...

 

Thanks again for looking into this.

[macattackjack]

And another thing, I just realized I haven't posted this before, but I'm using chameleon not cloverfield.

[Mieze]

And another thing, I just realized I haven't posted this before, but I'm using chameleon not cloverfield.

 

In most cases the bootloader doesn't affect network drivers at all, at least when it's configured correctly.

 

Mieze

[david_m]

Hi Mieze,

 

great to see this driver being worked on. I'm having trouble with the release candidate driver, getting transmit timeouts.

 

Motherboard is Asus H87M-PRO. I'm not completely sure which chip it is; this driver probes it as RTL8168G/8111G. Linux and windows have no issues with it at all.

 

OSX is 10.9.2. Anything I can do to help debug it? Log extract below.

Apr  6 21:13:20 localhost kernel[0]: Ethernet [RealtekRTL8111]: Warning: PCIe ASPM enabled.
Apr  6 21:13:20 localhost kernel[0]: Ethernet [RealtekRTL8111]: EEE support enabled.
Apr  6 21:13:20 localhost kernel[0]: Ethernet [RealtekRTL8111]: TCP/IPv4 segmentation offload enabled.
Apr  6 21:13:20 localhost kernel[0]: Ethernet [RealtekRTL8111]: TCP/IPv6 checksum offload enabled.
Apr  6 21:13:20 localhost kernel[0]: Ethernet [RealtekRTL8111]: Using interrupt mitigate value 0xcf68.
Apr  6 21:13:20 localhost kernel[0]: Ethernet [RealtekRTL8111]: RTL8168G/8111G: (Chipset 20) at 0xffffff81c645b000, ac:22: b:26:12:40
Apr  6 21:13:31 Davids-iMac kernel[0]: Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Apr  6 21:14:17 fuzzbox kernel[0]: Ethernet [RealtekRTL8111]: Tx timeout. Lost interrupt?
Apr  6 21:14:18 fuzzbox kernel[0]: Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0x8c5, IMR=0x0.
Apr  6 21:14:22 Davids-iMac kernel[0]: Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Apr  6 21:14:56 fuzzbox kernel[0]: Ethernet [RealtekRTL8111]: Tx timeout. Lost interrupt?
Apr  6 21:15:00 fuzzbox kernel[0]: Ethernet [RealtekRTL8111]: Tx timeout. Lost interrupt?
Apr  6 21:15:01 fuzzbox kernel[0]: Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0x8c5, IMR=0x803f.
Apr  6 21:15:04 Davids-iMac kernel[0]: Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control

[Mieze]

@david_m: Please try the development 6 build I posted earlier in this thread and report back. Also make sure you have disabled network boot in BIOS and that there are no other Realtek drivers installed on your system!

 

Mieze

[kokopellix]

Hi Miezi,

 

the last RC1 v1.2.0 kext is working great here.

Both NIC´s on GA Z77N WIFI working fine, but if i´m try Link Aggregation,Teaming or Bonding, however you will call it, i loose any connection local/inet after a few minutes, and i have to restart and do all the settings in network preferences again and again! Do you think it´s energy related, because there are no kp´s in the log files...

 

 

THX koko

[Mieze]

@kokopellix: Congratulations! You are the first user who successfully configured Link Aggregation. Unfortunately I don`t have any experience with Link Aggregation under OS X so that I'm not sure why it does`t work stable. It might be the switch which lacks support for LACP or maybe there is something missing in the driver. At least Apple's driver documentation doesn't mention LACP so that I'm not aware if there are any special requirements. I recently checked an ACPI dump of a XServe which suggests it could be a DSDT related problem.

 

Please run the following commands in Terminal and send me the output:

netstat -i
netstat -s
netstat -m
ifconfig -v -a
grep kernel /var/log/system.log 

Maybe I'll find something which helps me to get Link Aggregation running?

 

Mieze

[kokopellix]

@mieze

 

thx for fast reply, hopefully saved the right files....https://dl.dropboxusercontent.com/u/64451450/koko%20netstat.zip

 

koko

 

EDIT: SORRY, the Switch isn´t LACP compatible, waiting for the new switch i already ordered...