Jump to content

New Driver for Realtek RTL8111

Realtek RTL8111 driver

  • Please log in to reply
687 replies to this topic

#121
Maniac10

Maniac10

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 950 posts
  • Gender:Not Telling
It's windows 7 64bit. Let me explain a bit: I've got my internet connection through my wifi, and my LAN port is connected to a router with a windows 7 share. I can mount the shared drive in Finder and it works great, no disconnection problems so far. But the moment I try to copy or move a file in parallels then the connection is dropped instantly in both OSs. Then if I replug the cable it gets back up but it's dropped again the moment I try anything with files in windows. I can navigate folders just fine but the problem occurs when I move, edit or copy a file.

EDIT: oh, I'm using the "Bridge" mode in Parallels but it happens in "shared" mode too.
EDIT2: the same happens with Slice's driver, the only one fully working is Lnx2Mac's so far

#122
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 447 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

EDIT2: the same happens with Slice's driver, the only one fully working is Lnx2Mac's so far


If Slice's driver is affected too this rules out checksum and segmentation offload related issues. According to the log file the Windows side seems to flood the driver with packets it doesn't like. Although there is no deadlock the NIC doesn't seem to do any useful work once you started the transfer. Maybe you should use Wireshark to find out what's going on? As Lnx2mac is working there are two possible explanations for the behavior:
  • A firmware issue which would be really bad luck because there is no documentation at all (Lnx2mac uses older firmware than Slice and I do).
  • Jumbo frames because Slice and I we both do not support this feature. I would suggest to check this first.
Mieze

#123
Maniac10

Maniac10

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 950 posts
  • Gender:Not Telling
I'll try to do some tests with wireshark when I have some time. Thanks for your explanations Mieze.

#124
nozyczek

nozyczek

    InsanelyMac Protégé

  • Members
  • PipPip
  • 71 posts
Mieze,
Works good here on RTL8168E/8111E (Chipset 13). I will do some more testing using sleep/WOL etc and will report back.
Awesome job!
Thanks!

Update:
Sleep/AutoSleep/WOL work
WOD not tested

My full specs are here for anyone who is interested.

#125
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 447 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

TCP/IPv6 Checksum Offload Support


This is an experimental version which includes for TCP/UDP checksum offload over IPv6. It has been successfully tested on a RTL8111E-VL (chipset 16) but there still might be bugs and it's far from being ready to be used on productive systems. Nevertheless any feedback is highly appreciated. In particular I'm interested in

Ethernet [RealtekRTL8111]: L4 header offset

messages. Here's a short explanation why. The IPv6 header has a fixed size and unlike IPv4 it doesn't have a header length filed anymore, but there can be extension headers making it hard to find the TCP/UDP protocol header in a packet. That's why the NIC has to be supplied with the offset of the TCP/UDP header from the start of the packet when offloading TCP/UDP checksum calculation for IPV6 packets. If there are no extension headers the value 54 will make every packet happy but in case there are, you'll have to scan them all in order to find the layer 4 protocol header because unlike Windows and Linux, OS X doesn't provide this information to the driver.

As the network stack doesn't offload checksum calculation for IPSEC packets, this facilitates the job a little bit, but as of now I haven't seen any packet with extension header so that I don't know if the algorithm works as expected. If you rely on IPv6 in your network, you might be the man for the job.

Good luck!

Mieze

PS: Is there really no one who is willing to try it?

Attached Files


Edited by Mieze, 11 May 2013 - 02:54 AM.


#126
nozyczek

nozyczek

    InsanelyMac Protégé

  • Members
  • PipPip
  • 71 posts
I'm IPv4 but can test for regression if you like. Probably some time later today.

#127
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 447 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

I'm IPv4 but can test for regression if you like. Probably some time later today.


Thanks! Usually there are always a few IPv6 packets floating around even in an IPv4 network.

At first glance it looks like that the network stack is only offloading IPv6 packets without extension headers. Assuming that the driver framework was designed carefully this would make sense as it doesn't give the driver any hint about the location of the level 4 header. I started reading the kernel sources to verify this theory but unfortunately the network stack is quite complex so that I haven't been able to verify or refute my theory yet. Therefore any data is highly appreciated.

Mieze

#128
Mrengles

Mrengles

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 117 posts
  • Gender:Male
  • Location:United States
Hello Mieze hope all is well on your side of the pond.

Your new driver "Version 1.0.4" works great on my new Gigabyte GA-Z77N-WIFI with two RTL8111E gigabit ethernet ports. I'm very happy about this because the MITX motherboard is being used as an edge of network server.

I patched my DSDT to inject the NICs even though your driver shows properly in "About This Mac" System Information. The reason for injecting both of the RTL8111E controllers is because I'm looking to force there location. For example I want en0 to be named Ethernet 1, and en1 named Ethernet 2 from the start. This allows me to use DHCP reservations when Bonding "Trucking" the the two NICs with Apple Built-In Link Aggregation. I know this works because I've done it in the past with my SmallTree (Intel) 2 port Ethernet PCIe card, but this time the NICS are on two separate DSDT methods.

Can you please take a look over my DSDT...the edits are located at RP05, and RP06... and advise if they are correct?

The DSDT compiles without any errors or warnings, but I'm just not sure the DSDT is working because i'm still seeing the model as Realtek RTL8168E-VL/8111E-VL PCI Express Gigabit Ethernet in System Information and not what my DSDT should be injecting them as Realtek RTL8111E Gigabit Ethernet.

			 Device (ETH1)
			 {
				 Name (_ADR, Zero)
				 OperationRegion (GPIO, SystemIO, 0x0800, 0x06)
				 Field (GPIO, ByteAcc, NoLock, Preserve)
				 {
					 GO01, 8,
					 GO02, 8,
					 GO03, 8,
					 GO04, 8,
					 GO05, 8,
					 GP9, 1
				 }
				 Name (_PRW, Package (0x02)
				 {
					 0x09,
					 0x03
				 })
				 Method (EWOL, 1, NotSerialized)
				 {
					 If (LEqual (Arg0, One))
					 {
						 Or (GP9, One, GP9)
					 }
					 Else
					 {
						 And (GP9, Zero, GP9)
					 }
					 If (LEqual (Arg0, GP9))
					 {
						 Return (Zero)
					 }
					 Else
					 {
						 Return (One)
					 }
				 }
				 Method (_DSM, 4, NotSerialized)
				 {
					 Store (Package (0x12)
						 {
							 "AAPL,slot-name",
							 Buffer (0x08)
							 {
								 "Built-In"
							 },
							 "built-in",
							 Buffer (One)
							 {
								 0x00
							 },
							 "location",
							 Buffer (0x02)
							 {
								 "1"
							 },
							 "device-id",
							 Buffer (0x04)
							 {
								 0x68, 0x81, 0x00, 0x00
							 },
							 "revision-id",
							 Buffer (0x08)
							 {
								 0x06, 0x00, 0x00, 0x00
							 },
							 "subsystem-id",
							 Buffer (0x2C)
							 {
								 0x00, 0xe0, 0x00, 0x00
							 },
							 "subsystem-vendor-id",
							 Buffer (0x2C)
							 {
								 0x58, 0x14, 0x00, 0x00
							 },
							 "device_type",
							 Buffer (0x14)
							 {
								 "Ethernet Controller"
							 },
							 "model",
							 Buffer (0x21)
							 {
								 "Realtek RTL8111E Gigabit Ethernet"
							 }
						 }, Local0)
					 DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0))
					 Return (Local0)
				 }
				 }

The above code is what I used to edit the DSDT below.


Attached File  Gigabyte GA-Z77N-WiFi uEFI BIOS F2 DSDT.aml.zip   14.64KB   3 downloads

I've also attached a copy of my IOReg.

Attached File  Gigabyte GA-Z77N-WiFi uEFI BIOS F2 DSDT.aml.zip   14.64KB   3 downloads


Thanks in advanced! :cowboy:

Mrengles

#129
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 447 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats
Hello Mrengels,

I'm glad to hear that the driver is working well on your system. Although your patch is correct, IORegistry won't show the selected value of the model property because the driver itself updates the value in it's configureInterface() routine, overwriting your changes. Please take a look at this code sequence:

bool RTL8111::configureInterface(IONetworkInterface *interface)
{
char modelName[kNameLenght];
IONetworkData *data;
bool result;
DebugLog("configureInterface() ===>\n");
result = super::configureInterface(interface);

if (!result)
	 goto done;

/* Get the generic network statistics structure. */
data = interface->getParameter(kIONetworkStatsKey);

if (data) {
	 netStats = (IONetworkStats *)data->getBuffer();
	
	 if (!netStats) {
		 IOLog("Ethernet [RealtekRTL8111]: Error getting IONetworkStats\n.");
		 result = false;
		 goto done;
	 }
}
/* Get the Ethernet statistics structure. */
data = interface->getParameter(kIOEthernetStatsKey);

if (data) {
	 etherStats = (IOEthernetStats *)data->getBuffer();
	
	 if (!etherStats) {
		 IOLog("Ethernet [RealtekRTL8111]: Error getting IOEthernetStats\n.");
		 result = false;
		 goto done;
	 }
}
unitNumber = interface->getUnitNumber();
snprintf(modelName, kNameLenght, "Realtek %s PCI Express Gigabit Ethernet", rtl_chip_info[linuxData.chipset].name);
setProperty("model", modelName);

DebugLog("configureInterface() <===\n");
done:
return result;
}

I guess you are familiar with the basics of C programming, aren't you? Commenting out the following 2 lines will prevent it from overwriting the model name:

snprintf(modelName, kNameLenght, "Realtek %s PCI Express Gigabit Ethernet", rtl_chip_info[linuxData.chipset].name);
setProperty("model", modelName);

Good luck!

Mieze

#130
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 1,107 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars
Mieze,

Last week, I had a reason to use my GBe ethernet port on my ProBook 4530s to transfer some large files (DVD backups ~5GB) to my server (Windows Home Server 2011 -- so, SMB shares). What I found is that I'm not getting throughput even close to GBe. According to Activity Monitor, more like 20mbit/sec...

Performance peaks at ~10MB/sec (more of a short spike) with your driver, average around 2MB/sec.

With lnx2mac, peak is ~49MB/sec and average around ~30MB/sec.

Here is the startup output from system.log:

May 18 17:30:47 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: Warning: PCIe ASPM enabled.
May 18 17:30:47 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: EEE support enabled
May 18 17:30:47 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: RTL8168E/8111E: (Chipset 14) at 0xffffff80ef566000, 10:1f:74:f2:f7:ef
May 18 17:30:50 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control

Obviously negotiating at 1-gigabit, but throughput is nowhere near...

What should I look at?

This is with your latest binaries, BTW...

#131
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 447 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Performance peaks at ~10MB/sec (more of a short spike) with your driver, average around 2MB/sec.

With lnx2mac, peak is ~49MB/sec and average around ~30MB/sec.


Both results are lousy, even on an Atom D425 system (chipset 9) I'm getting better performance using Blackmagic Disk Speed Test over an AFP connection and with a better CPU a stable throughput of 110MB/s in both directions is possible (chipset 16).

May 18 17:30:47 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: Warning: PCIe ASPM enabled.

Obviously Active State Power Management (ASPM) is enabled on your Probook which is known to cause serious problems with the Realtek chips. Another point is that nozyczek reported a performance issue with chipset 13. Maybe chipset 14 is affected too? I'm currently investigating this issue but still haven't found a solution.

Please try the attached version and report back. Try to disable TSO4 (please see Info.plist) and check if this helps to improve performance. Check the netstat -s output for the number of retransmitted TCP packets.

You might also try Slices's driver in order to narrow down the cause of the problem because it is based on the same linux sources but does a few things different, in particular it doesn't make use of the offload features.

Mieze

Attached Files



#132
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 1,107 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

Both results are lousy, even on an Atom D425 system (chipset 9) I'm getting better performance using Blackmagic Disk Speed Test over an AFP connection and with a better CPU a stable throughput of 110MB/s in both directions is possible (chipset 16).


I will try setting up my desktop as AFP and see how that compares. I'm sure Apple's implementation of SMB is not ideal, but obviously the driver is playing a big part it in this separate from the protocol.

Obviously Active State Power Management (ASPM) is enabled on your Probook which is known to cause serious problems with the Realtek chips. Another point is that nozyczek reported a performance issue with chipset 13. Maybe chipset 14 is affected too? I'm currently investigating this issue but still haven't found a solution.


OK. Is there some way I can disable ASPM as a test?

Please try the attached version and report back. Try to disable TSO4 (please see Info.plist) and check if this helps to improve performance. Check the netstat -s output for the number of retransmitted TCP packets.


I tried the driver you posted with and without TSO4. No material difference from the previous driver.

netstat -s | grep -y retrans:

2 data packets (669 bytes) retransmitted
63 retransmit timeouts
0 connections dropped after retransmitting FIN

You might also try Slices's driver in order to narrow down the cause of the problem because it is based on the same linux sources but does a few things different, in particular it doesn't make use of the offload features.


I tried Slice's driver and get ~10.6MB/sec sustained, 10.7MB/sec peak. His driver only seems to support 100mbit/sec. Link speed is shown 100 Mbit/sec in Network Utility.

#133
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 447 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

OK. Is there some way I can disable ASPM as a test?


I'll try to find a solution and will provide you a test version as soon as possible. dmazar, who is using the same hardware than you, send me a lot of debug data. The funny thing is, that most of his logs show ASPM to be disabled, while it was enabled on others. In any case it would be a real help if he could find out why? Maybe we should try to contact him just in case he isn't following the discussion right now?

netstat -s | grep -y retrans:


2 data packets (669 bytes) retransmitted
63 retransmit timeouts
0 connections dropped after retransmitting FIN


Ok, this looks good. No packet loss. No problems with TSO. This leaves ASPM and the PHY configuration as possible candidates.

I tried Slice's driver and get ~10.6MB/sec sustained, 10.7MB/sec peak. His driver only seems to support 100mbit/sec. Link speed is shown 100 Mbit/sec in Network Utility.


Looks like the strange behavior only arises with gigabit speed because dmazar is using 100Mbit only and he didn't seem to be affected.

Mieze

PS: At first glance it looks like the initialization routines always enable ASPM on chipset 13 and 14 but I'll have to dig deeper into the code which isn't trivial because Realtek doesn't provide any docs.

Edit2: Can you please provide me a dump of the NIC's PCI config space under Win7?

Edited by Mieze, 19 May 2013 - 08:20 PM.


#134
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 1,107 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

I will try setting up my desktop as AFP and see how that compares. I'm sure Apple's implementation of SMB is not ideal, but obviously the driver is playing a big part it in this separate from the protocol.


OK... more info here. I setup my desktop as AFP (running hnak's AppleIntele1000e) and copied a file from it. Result: ~100MB/sec average and ~115MB/sec peak. In same session, copied a file from my Windows server, and result is back down to 2MB/sec.

So there is something that happens with SMB protocol, not happening with AFP.

Also, just for comparison, I get about ~59MB/sec from my Windows server (SMB) to my desktop (hnak's driver)...

#135
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 447 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

OK... more info here. I setup my desktop as AFP (running hnak's AppleIntele1000e) and copied a file from it. Result: ~100MB/sec average and ~115MB/sec peak. In same session, copied a file from my Windows server, and result is back down to 2MB/sec.

So there is something that happens with SMB protocol, not happening with AFP.

Also, just for comparison, I get about ~59MB/sec from my Windows server (SMB) to my desktop...



Hello RehabMan,

the AFP results are quite good. In any case, could you please try the attached version. It disables ASPM and Clock Request and it would be good to know if there is any impact on performance? At least I would like to know if it works at all?

With regard to the SMB issue, I think that Wireshark is the weapon of choice!

Good luck!

Mieze

EDIT: I can reproduce the issue on my homeserver running 10.8.3 server (chipset 16) when I try to copy a file to it via SMB.

Attached Files



#136
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 1,107 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

Hello RehabMan,

the AFP results are quite good. In any case, could you please try the attached version. It disables ASPM and Clock Request and it would be good to know if there is any impact on performance? At least I would like to know if it works at all?

With regard to the SMB issue, I think that Wireshark is the weapon of choice!

Good luck!

Mieze

EDIT: I can reproduce the issue on my homeserver running 10.8.3 server (chipset 16) when I try to copy a file to it via SMB.


Never have used WireShark... Not really a network protocol expert, so I'm not sure I'll understand what I'm looking at, but...

FYI: I tried this version, and the results are the same. So, it does work... but still slowly...

Nice to hear you can repro the problem using Apple's SMB server implementation. Maybe you can figure something out?

#137
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 447 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

Never have used WireShark... Not really a network protocol expert, so I'm not sure I'll understand what I'm looking at, but...

FYI: I tried this version, and the results are the same. So, it does work... but still slowly...

Nice to hear you can repro the problem using Apple's SMB server implementation. Maybe you can figure something out?


Well, I will have to do it myself ASAP. The funny thing is that when my homeserver with the Realtek NIC is the

Server
  • Reading a file from it is fast.
  • Writing a file to it is slow.
Client
  • Reading a file from another server is fast.
  • Writing a file to another server is slow.
Does this make any sense? :unsure:

Mieze

#138
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 447 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats
Yeah! I think I got it. Please take a look at the file RealtekRTL8111.h and increase kMaxSegs from 24 to 64. This helped to improve performance on my machine. Let's see if it helps you too?

Mieze

#139
RehabMan

RehabMan

    InsanelyMac Legend

  • Coders
  • 1,107 posts
  • Gender:Male
  • Location:Bellingham, WA
  • Interests:skiing, software, classic cars

Yeah! I think I got it. Please take a look at the file RealtekRTL8111.h and increase kMaxSegs from 24 to 64. This helped to improve performance on my machine. Let's see if it helps you too?

Mieze


No go for me... I made the change to CO6-experimental2 and have the same results. For grins, I even tried 128.

I'm going to try running SMB instead of AFP on my desktop for comparison Mac<->Mac (smb) vs. Windows<->Mac (smb).


Edit: I was able to reproduce your results as far as SMB on Apple server. Copying from ProBook to OS X 10.8.3 SMB share is relatively fast (~30MB/sec) whereas copying from the SMB share to the ProBook is slow (~2MB/sec). This is in contrast to the SMB on my Windows server, which is slow (~2MB/sec) in both directions. Interesting?

#140
Mieze

Mieze

    InsanelyMac Sage

  • Coders
  • 447 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

No go for me... I made the change to CO6-experimental2 and have the same results. For grins, I even tried 128.

I'm going to try running SMB instead of AFP on my desktop for comparison Mac<->Mac (smb) vs. Windows<->Mac (smb).


Edit: I was able to reproduce your results as far as SMB on Apple server. Copying from ProBook to OS X 10.8.3 SMB share is relatively fast (~30MB/sec) whereas copying from the SMB share to the ProBook is slow (~2MB/sec). This is in contrast to the SMB on my Windows server, which is slow (~2MB/sec) in both directions. Interesting?


I've captured the traffic with Wireshark and found a lot of malformed SMB packets. I used to send received packets up the network stack without the ethernet CRC and now changed it so that the upper level now gets the full packet including the 4 byte CRC checksum. I don't know why, but Wireshark shows that the number ob SMB errors has been radically reduced to only a few instead of hundreds.

With the attached version performance has improved too. I've got the following results with Blackmagic Disk Speed Test over SMB:

Realtek (Server) <---> Broadcom in iMac 2011 (Client)
Read: ~75MB/sec
Write: 5-50MB/sec but very unstable (It's strange! I'm able to boost this value up to more then 60BM/sec (stable) when doing an AFP write simultaneously!!!)

Broadcom in Mac mini 2011 (Server) <---> Realtek (Client) I guess the slow HD of Mac mini is the limiting factor here!
Read: 40-60MB/sec
Write: 40-60MB/sec

Mieze

@Maniac10: Please try this version too in order to see if it resolves the Parallels issue!

Attached Files


Edited by Mieze, 20 May 2013 - 04:56 AM.







1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy