Jump to content

New Driver for Realtek RTL8111

Mieze

By Mieze,
in LAN and Wireless

 Share
1,593 posts in this topic

Recommended Posts

Pasarel
Pasarel
Posted
Posted

Hi, sorry to bother, but I didn't manage for the life of me to get your driver to work.

In the network manager it simply tells me that either the cable is unplugged (which it isn't) or the device at the other end (an Asus AC-56U gigabit Ethernet router) is not responding.

I have installed the debug version of your driver, and will attach the output of netstat, /var/log/system.log and dmesg.

In the Info.plist I have deactivated checksum offloading, so to have fewer possible points of failure (previously I had jumbo frames activated, but read that they can interfere with the checksum calculation).

Also, I have tried resetting my router to factory defaults, to no avail.

I can also attach a sample of Wireshark if needed, but I couldn't personally make much out of it, both the PC and the router seem confused.

I know you said that npci=0x2000 can interfere with the driver, but my Hackintosh (Gigabyte 990FXA-UD3, Mavericks 10.9.5 and this kernel) doesn't boot past the PCI enumeration step without this kernel flag.

driver_debug.zip

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

@Pasarel: The log file looks quite normal, at least with regard to the driver except the fact that the link isn't established. You might try to delete the network interface in System Preferences as well as /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist and recreate the interface after a reboot but in case this doesn't help there is little more I could do for you. It might also be a DSDT problem or a result of npci=0x2000 but I must confess that I have absolutely no experience with hackintoshing AMD systems.

 

Mieze

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

What is strange is that Lnx2Mac's driver works... sort of... it is very unstable but it does allow me to connect now and then to the Internet.

P.S. I haven't touched my DSDT table.

 

Lnx2mac uses the NIC's IO space in order to access its registers while my driver uses the memory space which is faster and is the the preferred method to access devices on the PCIe bus (IO space access is considered to be legacy). That's the reason why I recommend to avoid npci=0x2000 as it makes PCIe memory space prefetchable (according to my information).

 

Mieze

Link to comment
Share on other sites
MacUser2525
MacUser2525
Posted
Posted

Hi, sorry to bother, but I didn't manage for the life of me to get your driver to work.

In the network manager it simply tells me that either the cable is unplugged (which it isn't) or the device at the other end (an Asus AC-56U gigabit Ethernet router) is not responding.

I have installed the debug version of your driver, and will attach the output of netstat, /var/log/system.log and dmesg.

In the Info.plist I have deactivated checksum offloading, so to have fewer possible points of failure (previously I had jumbo frames activated, but read that they can interfere with the checksum calculation).

Also, I have tried resetting my router to factory defaults, to no avail.

I can also attach a sample of Wireshark if needed, but I couldn't personally make much out of it, both the PC and the router seem confused.

I know you said that npci=0x2000 can interfere with the driver, but my Hackintosh (Gigabyte 990FXA-UD3, Mavericks 10.9.5 and this kernel) doesn't boot past the PCI enumeration step without this kernel flag.

 

Doubt it is the router I have the same model it works perfectly fine here, not much use to you other than knowing it works ok with this driver and my card. Personally I would go with an AMD related problem somewhere in the mix causing it.

Link to comment
Share on other sites
Pasarel
Pasarel
Posted
Posted

I think if it were an AMD related issue, my Linux wouldn't be working either - which indeed was the case when I first bought the motherboard. Apparently some chipsets - 990FX included - implement this new hardware virtualization technology called AMD-Vi (equivalent of Intel VT-D) via an IOMMU.

To this day, I failed to understand what it's good for. If I let it enabled, my dmesg output would get full of outputs like this:

[   46.215678] AMD-Vi: Event logged [IO_PAGE_FAULT device=02:00.0 domain=0x0000 address=0x0000000000100000 flags=0x0050]

Where the PCI device located at 02:00.0 would be a VIA USB controller.

I had to disable it in the UEFI/BIOS, and then add "iommu=soft" in the boot parameters, so that the Linux kernel could emulate that in software. Only that way could I get Ethernet and USB 3.0 working.

 

What I do suspect as being a culprit in this case would be the DSDT table. At the moment, I only have a vague idea what it is and what it does. I don't know 100% for sure if my system needs DSDT patches, but what I do know is that I do have other problems as well: I can't get full QE/CI with my Gainward GT218 nVidia graphics card.

 

My plan is:

- learn about DSDT tables and other ACPI stuff

- hopefully patch my Gigabyte 990FXA-UD3 rev 4.0 so that I can get rid of "npci=0x2000" in boot flags

- now that I can boot without npci, HOPEFULLY that was the problem with your driver, and it'll work too.

- profit!

 

I know I digress a lot, and I shouldn't be talking at all about graphics in a networking driver thread, but as I found out, in the hackintoshing world, everything is related to everything.

Link to comment
Share on other sites
  • 4 weeks later...
calibre™
calibre™
Posted
Posted

Hello Mieze

Any idea about the this error... (I followed Troubleshooting in post #1)

 

System profiler shows:

Realtek RTL8168B/8111B PCI Express Gigabit Ethernet
  Device ID:	0x8168
  Subsystem Vendor ID:	0x1458
  Subsystem ID:	0xe000
  Revision ID:	0x0002

Ethernet [RealtekRTL8111]: EEE support enabled.
Ethernet [RealtekRTL8111]: TCP/IPv4 segmentation offload enabled.
Ethernet [RealtekRTL8111]: TCP/IPv6 segmentation offload enabled.
Ethernet [RealtekRTL8111]: TCP/IPv6 checksum offload enabled.
Ethernet [RealtekRTL8111]: Version 1.2.3 using interrupt mitigate value 0xcf58.
unknown chip version (7c800000)
unknown chip version (7c800000)
Ethernet [RealtekRTL8111]: RTL8168B/8111B: (Chipset 0) at 0x35245000, ff:ff:ff:ff:ff:ff
RTL8111: Ethernet address ff:ff:ff:ff:ff:ff
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Ethernet [RealtekRTL8111]: Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
tun kernel extension version 20111101 <mattias.nissler@gmx.de>
tap kernel extension version 20111101 <mattias.nissler@gmx.de>
Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Ethernet [RealtekRTL8111]: 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
Ethernet [RealtekRTL8111]: 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
Ethernet [RealtekRTL8111]: 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
Ethernet [RealtekRTL8111]: 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
Ethernet [RealtekRTL8111]: 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
Ethernet [RealtekRTL8111]: Tx timeout. Lost interrupt?
Ethernet [RealtekRTL8111]: Tx stalled? Resetting chipset. ISR=0xffff, IMR=0xffff.
Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

The driver is unable to determine the correct chipset. Which mainboard are you using or is the NIC located on an add-in card?

 

Mieze

  • Like 1
Link to comment
Share on other sites
calibre™
calibre™
Posted
Posted

Hello Mieze, Thank You so much for replying :)

Im using 945GCM-S2L and the Lan is built-in

 

 

GA site specs shows as: http://www.gigabyte.com/products/product-page.aspx?pid=2669#sp

LAN          RTL 8111C chip (10/100/1000 Mbit)

lspci shows:

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 02)
Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

 

Hello Mieze, Thank You so much for replying :)

Im using 945GCM-S2L and the Lan is built-in

 

 

GA site specs shows as: http://www.gigabyte.com/products/product-page.aspx?pid=2669#sp

LAN          RTL 8111C chip (10/100/1000 Mbit)

lspci shows:

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 02)

 

I'm afraid, but there is nothing I can do for you as the driver is unable to identify the chip. As there is no documentation on how to do this, I must use the unaltered routine from the underlying linux driver and I don't want to experiment because it might have unpredictable results or even damage the hardware.

 

Mieze

Link to comment
Share on other sites
luxinhaus
luxinhaus
Posted
Posted

Hello Mieze, Thank You so much for replying :)

Im using 945GCM-S2L and the Lan is built-in

 

 

GA site specs shows as: http://www.gigabyte.com/products/product-page.aspx?pid=2669#sp

 

LAN          RTL 8111C chip (10/100/1000 Mbit)
lspci shows:

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 02)

You happened to be on the latest bios which is F8d beta? if yes, downgrade to F7. i can guarantee that it will work as long youl follow "troubleshoot" from post 1

  • Like 1
Link to comment
Share on other sites
coudy
coudy
Posted
Posted

Hi Mieze, 

I'm using your driver 1.2.3 on my Asrock 4core1600-GLAN motherboard. In basic, driver is working, but I have problem with download speed. I used iperf to test throughput. Download speed is around 10-15Mbit/s. I'm on Gigabit network.

iperf -c nas -i5 -t30
------------------------------------------------------------
Client connecting to nas, TCP port 5001
TCP window size:  129 KByte (default)
------------------------------------------------------------
[  5] local 192.168.2.10 port 50593 connected with 192.168.2.5 port 5001
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0- 5.0 sec  2.88 MBytes  4.82 Mbits/sec
[  5]  5.0-10.0 sec  8.75 MBytes  14.7 Mbits/sec
[  5] 10.0-15.0 sec  8.00 MBytes  13.4 Mbits/sec
[  5] 15.0-20.0 sec  8.62 MBytes  14.5 Mbits/sec
[  5] 20.0-25.0 sec  8.62 MBytes  14.5 Mbits/sec
[  5] 25.0-30.0 sec  8.62 MBytes  14.5 Mbits/sec
[  5]  0.0-30.0 sec  45.6 MBytes  12.7 Mbits/sec

Upload speed is correct, about 930Mbit/s

iperf -s -i5
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  4] local 192.168.2.10 port 5001 connected with 192.168.2.5 port 34583
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0- 5.0 sec   555 MBytes   932 Mbits/sec
[  4]  5.0-10.0 sec   556 MBytes   933 Mbits/sec
[  4] 10.0-15.0 sec   557 MBytes   934 Mbits/sec
[  4] 15.0-20.0 sec   548 MBytes   920 Mbits/sec
[  4] 20.0-25.0 sec   549 MBytes   920 Mbits/sec
[  4] 25.0-30.0 sec   555 MBytes   931 Mbits/sec
[  4]  0.0-30.0 sec  3.25 GBytes   929 Mbits/sec

I have tried this, but still I have problem with speed.

  • older driver version 1.2.2
  • another kext found on internet
  • original 8169 driver from Realtek
  • disabled PXE on bios

 

This is my NIC:


Realtek RTL8168C/8111C PCI Express Gigabit Ethernet:

  Name:    ethernet
  Type:    Radič ethernetu
  Bus:    PCI
  Vendor:    0x10ec
  Device:    0x8168
  Sub Ven:    0x1849
  Sub Dev:    0x8168
  Revision:    0x0002
  Name BSD:    en0
  Kext name:    RealtekRTL8111.kext
  Path:    /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/RealtekRTL8111.kext
  Version:  1.2.3
Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

@coudy: First of all, what do you mean with upload and download because it is unclear which machine is sending and which is receiving? Second, tell me more about the machine on the other side. Which OS, NIC, etc. ?

 

Mieze

Link to comment
Share on other sites
coudy
coudy
Posted
Posted

Hi,

tested was my pc with Yosemite. When iperf is running with parameter -c it means connect to another server, so my pc is downloading data. In second test I run iperf with -s parameter, which mean, act as server, so my pc was sending data to another machine.

 

My pc : OSX Yosemite, MB Asrock 4core1600-Glan http://www.asrock.com/mb/Intel/4Core1600-GLAN/

NIC:  PCIE x1 Gigabit LAN 10/100/1000 Mb/s ,Realtek RTL8111B/RTL8111C

Link to comment
Share on other sites
coudy
coudy
Posted
Posted

Are you sure ? According to docs, https://iperf.fr/ when iperf is run in client (iperf -c server_ip) mode, it downloads data from the server (iperf -s)

 

yosemite: iperf -c nas

nas: iperf -s

= yosemite is reading data from nas

 

anyway, on my NAS is Debian stable, then I have tried Dell notebook with Manjaro.

I have tried connect from Yosemite to Nas or Dell, speed is always 10-15Mbit/s.

When I try connection between Nas <> Dell, throughput is about 930Mbit/s

 

When I reverse direction, and my Yosemite act as server, clients on Nas or Dell show throughput about 930Mbit/s.

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

Are you sure ? According to docs, https://iperf.fr/ when iperf is run in client (iperf -c server_ip) mode, it downloads data from the server (iperf -s)

 

yosemite: iperf -c nas

nas: iperf -s

= yosemite is reading data from nas

 

anyway, on my NAS is Debian stable, then I have tried Dell notebook with Manjaro.

I have tried connect from Yosemite to Nas or Dell, speed is always 10-15Mbit/s.

When I try connection between Nas <> Dell, throughput is about 930Mbit/s

 

When I reverse direction, and my Yosemite act as server, clients on Nas or Dell show throughput about 930Mbit/s.

 

No, client mode means that iperf is sending data to the server. Try to disable TSO in the driver's Info.plist and see if it helps. Don't forget to recreate the kernel cache after performing the change. For instructions see post#1 or search the thread.

 

Mieze

Link to comment
Share on other sites
coudy
coudy
Posted
Posted

sorry, my bad, you have right.

 

Disabling TSO helped, it is better, but 100Mbit/s slower than download. Download is about 930Mbit/s, Upload is 830Mbit/s.

Is there a chance how to increase upload ?

 

Thank You

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

The cause of the problem lies on the other side because it doesn't accept packets fast enough to reach full speed. That's also the reason why TSO is causing trouble. You'll have to dig deep into the TCP configuration of this machine, but I leave this task up to you because I don't have a quick answer.

 

Mieze

  • Like 1
Link to comment
Share on other sites
calibre™
calibre™
Posted
Posted

You happened to be on the latest bios which is F8d beta? if yes, downgrade to F7. i can guarantee that it will work as long youl follow "troubleshoot" from post 1

That did it! downgraded, now Mieze's kext works :)

 

Thanks Mieze and Luxinhaus :)

Link to comment
Share on other sites
BartMan01
BartMan01
Posted
Posted

Having issues with my GA-X58A-UD5 built in Ethernet.  I was getting very frequent occurances where Ethernet would just stop working.  I put in the debug version of the driver and suprisingly things got much more stable with that.  I have gone from several times a day to just once in the last few days.  Still trying to catch it in the act with the debug driver in place (as opposed to a while after it happened with no clear idea what time it occured).  One thing I am seeing a lot of in the logs is the following:

 

Apr  3 05:52:38 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Not enough descriptors. Stalling.
Apr  3 05:52:38 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Restart stalled queue!
Apr  3 05:52:38 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Not enough descriptors. Stalling.
Apr  3 05:52:38 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Restart stalled queue!
Apr  3 05:52:38 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Not enough descriptors. Stalling.
Apr  3 05:52:38 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Restart stalled queue!
Apr  3 05:52:38 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Not enough descriptors. Stalling.
Apr  3 05:52:38 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Restart stalled queue!
Apr  3 05:52:38 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Not enough descriptors. Stalling.

 

... no other RTL8111 entries, at this point I restarted the switch and:

Apr  3 09:24:25 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Link down on en0
Apr  3 09:24:25 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Promiscuous mode disabled.
Apr  3 09:24:32 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
Apr  3 09:24:32 Zeus kernel[0]: Ethernet [RealtekRTL8111]: Promiscuous mode enabled.

 

As far as I can tell the 'not enought descriptors' messages have not come back yet.

 

I suspect that Ethernet stopped working at 5:52:38 when it stalled but did not restart the stalled queue.

 

Any ideas?  Suggestions on troubleshooting this?

 

One thing I have thought of doing was swithing to the second ethernet port on the motherboard to see if it has the same issues.  Worth a try?

 

Thanks.

 

Edit: Additional info:

Been happening for a while.

Tried replacing both cable and switch to rule them out.

Very intermittent but seems to happen most often in the middle of large sustained file transfers.

Link to comment
Share on other sites
Mieze
Mieze
Posted
  • Author
Posted

@BartMan01: This is not a driver bug, it's the network stack that causes the issue and it's quite frequent on Yosemite. The network stack is flooding the driver with packets eating up all available packet buffer memory so that the interface freezes. When you disconnect the cable, all resources associated with the interface are freed so that it is able to resume work after the connection has been reestablished.

 

Mieze

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...