New Driver for Realtek RTL8111

[nozyczek]

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

[Mieze]

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

[Mrengles]

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.

 

 

 

 

I've also attached a copy of my IOReg.

 

 

 

 

Thanks in advanced!

 

Mrengles

[Mieze]

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

[RehabMan]

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...

[Mieze]

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

RealtekRTL8111-CSO6-experimental2.zip

[RehabMan]

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.

[Mieze]

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 May 19, 2013 by Mieze

[RehabMan]

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)...

[Mieze]

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.

RealtekRTL8111-RehabMan.zip

[RehabMan]

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?

[Mieze]

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?

 

Mieze

[Mieze]

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

[RehabMan]

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?

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

 

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!

RealtekRTL8111-RehabMan2.zip

Edited May 20, 2013 by Mieze

[RehabMan]

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!

 

Performance with this version seems slightly better, but not the order of magnitude (and more) we should be seeing. I'm now getting 3-4MB/sec reads...

 

I will do some tests with BlackMagic later just so we are using the same performance test...

 

I also tried setting delayed_ack=0 as suggested here: http://www.techkaki.com/2010/12/slow-samba-file-copying-speeds-in-mac-os-x/

It didn't seem to help...

[Mieze]

Performance with this version seems slightly better, but not the order of magnitude (and more) we should be seeing. I'm now getting 3-4MB/sec reads...

 

I will do some tests with BlackMagic later just so we are using the same performance test...

 

I also tried setting delayed_ack=0 as suggested here: http://www.techkaki....ds-in-mac-os-x/

It didn't seem to help...

 

I'm in a hurry: Try too disable EEE too! I assume that there is an unfavorable interference between EEE shutting down the transmitter in phases of inactivity and the SMB protocol timing. I will test this later when I have time.

 

Mieze

Edited May 20, 2013 by Mieze

[RehabMan]

I'm in a hurry: Try too disable EEE too! I assume that there is an unfavorable interference between EEE shutting down the transmitter in phases of inactivity and the SMB protocol timing. I will test this later when I have time.

 

Mieze

 

Tried disabling EEE (also tried disabling the other options in Info.plist). No joy here. Also tried running debug version, just to see if there was any bad things happening. Only one 'replaceOrCopyPacket' failed message (filtered for 'rtl8111'):

 

May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: PCI power management capabilities: 0xffc3.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: PME# from D3 (cold) supported.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: PCIe link capabilities: 0x00073c11, link control: 0x0143.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: Warning: PCIe ASPM enabled.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: EEE support disabled.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: TCP/IPv4 segmentation offload disabled.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: TCP/IPv6 checksum offload disabled.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: RTL8168E/8111E: (Chipset 14) at 0xffffff80ef536000, 10:1f:74:f2:f7:ef
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: MSI interrupt index: 1
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: kIOEthernetWakeOnMagicPacket added to filters.
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: Already in power state 1.
May 20 08:25:29 ProBook-ML kernel[0]: RTL8111: Ethernet address 10:1f:74:f2:f7:ef
May 20 08:25:29 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: No medium selected. Falling back to autonegotiation.
May 20 08:25:31 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: Link up on en0, 1-Gigabit, Full-duplex, flow-control
May 20 08:25:58 ProBook-ML kernel[0]: Ethernet [RealtekRTL8111]: replaceOrCopyPacket() failed.

 

BTW, thanks for all your help on this...

 

I may play w/ Slice's driver next and see if I can get it to negotiate link speed @1000...

 

Edit: Managed to get slice's driver to work at 1000. Had to force it in SysPrefs -> Network -> Advanced -> Hardware. Once I did that, I get average ~45MB/sec to/from my Windows server and peak to ~55MB/sec. Maybe can figure out the difference between your version and slice's?

[Mieze]

Managed to get slice's driver to work at 1000. Had to force it in SysPrefs -> Network -> Advanced -> Hardware. Once I did that, I get average ~45MB/sec to/from my Windows server and peak to ~55MB/sec. Maybe can figure out the difference between your version and slice's?

 

A few weeks ago we had a personal conversation with him about driver development and Slice told me that he had changed something in the PHY initialization. I will check his messages later to see what it is.

 

Mieze

[Mieze]

Hello RehabMan,

 

here is what Slice mentioned:

 

"See my procedures RTL8168PowerDownPHY() and RTL8168PowerUpPHY()"

 

Maybe it will help you to figure out what is different.

 

By the way I disabled EEE too and it didn't resolve the issue completely. When the Realtek chip is the client, I get stable data rates of ~75MB/sec in both directions, but when the Realtek chip is the server reads are just as fast but writes are still slow.

 

The funny thing is the speedup, when there is additional traffic, even to the same SMB share. I started a copy operation of a 2GB file to the SMB share and it was slow (estimated time to complete more than 4 minutes). Then I started a second copy operation of another 2GB file and now both copy operations are accelerated dramatically (estimated time to complete less than 1 minute on both).

 

So I guess it isn't a pure hardware issue. From my point of view it seems to be more like a timing issue of the protocol in combination with the driver.

 

Mieze

[Mieze]

Hello RehabMan,

 

I ran some small tests with Win7 using the poor Atom copying some large files from and to the Mac server with the Realtek NIC and got a throughput between 30-50MB/sec according to the time it took to complete the transfer. That is roughly what I expected with this hardware.

 

Also tried to use the Win7 machine as the server with the Mac server as the client. The performance was comparable to the results I got in the other scenario described above.

 

Mieze

[RehabMan]

Hello RehabMan,

 

I ran some small tests with Win7 using the poor Atom copying some large files from and to the Mac server with the Realtek NIC and got a throughput between 30-50MB/sec according to the time it took to complete the transfer. That is roughly what I expected with this hardware.

 

Also tried to use the Win7 machine as the server with the Mac server as the client. The performance was comparable to the results I got in the other scenario described above.

 

Mieze

 

Thanks for trying that. I could be something to do with settings on my server, I suppose... Is your test as you mention above, realtek<->realtek or does your server have a different NIC? I have 5 "desktop" computers here and one laptop (a few tablets too, but...). Unfortunately, all the desktop systems are built on the same platform: Intel DH67xx with Intel 82579 NIC. Probook is my only Realtek.

 

This is 'by design' having been burned in the past by poor performing Realtek NICs, I avoided it in all my desktop builds...

 

But I will play around w/ the settings on the 82579 and see if there is something I can tweak there.

 

Otherwise, I will try to fix slice's driver (two problems I see so far: doesn't auto-negotiate 1000mbit, and doesn't work at all after sleep). Those problems, for me, might be more fixable than trying to fix this issue in yours...

 

At any rate, I'll let you know if I make any progress...

 

Thanks!

[Mieze]

Thanks for trying that. I could be something to do with settings on my server, I suppose... Is your test as you mention above, realtek<->realtek or does your server have a different NIC? I have 5 "desktop" computers here and one laptop (a few tablets too, but...). Unfortunately, all the desktop systems are built on the same platform: Intel DH67xx with Intel 82579 NIC. Probook is my only Realtek.

 

My homeserver uses a MSI B75MA-P45 (i3 3225) with an RTL8111E-VL (chipset 16).

The test machine uses an Foxconn D42s (Atom D425) with an RTL8111D (chipset 9).

The 2011 iMac and Mac mini have a Broadcom 57765.

 

This is 'by design' having been burned in the past by poor performing Realtek NICs, I avoided it in all my desktop builds...

 

But I will play around w/ the settings on the 82579 and see if there is something I can tweak there.

 

Otherwise, I will try to fix slice's driver (two problems I see so far: doesn't auto-negotiate 1000mbit, and doesn't work at all after sleep). Those problems, for me, might be more fixable than trying to fix this issue in yours...

 

Taking all the facts into account, in particular the reports of similar problems with Apple hardware, I wouldn't call this a hardware issue. I rather think that there is a serious problem in Apple's SMB stack with regard to timing. With scatter-gather-DMA and task offload the drivers timing becomes less predictable and as my driver's architecture is very similar to the network drivers of recent Macs, its no no wonder that there are similar problems. The main difference is that Apple seems to have found a hack to get it working with their hardware.

 

Mieze

[RehabMan]

My homeserver uses a MSI B75MA-P45 (i3 3225) with an RTL8111E-VL (chipset 16).

The test machine uses an Foxconn D42s (Atom D425) with an RTL8111D (chipset 9).

The 2011 iMac and Mac mini have a Broadcom 57765.

 

Thanks for the info...

 

Taking all the facts into account, in particular the reports of similar problems with Apple hardware, I wouldn't call this a hardware issue. I rather think that there is a serious problem in Apple's SMB stack with regard to timing. With scatter-gather-DMA and task offload the drivers timing becomes less predictable and as my driver's architecture is very similar to the network drivers of recent Macs, its no no wonder that there are similar problems. The main difference is that Apple seems to have found a hack to get it working with their hardware.

 

And that lnx2mac and slice's driver do not exhibit this problem...

 

I'll let you know what I find out when I have some time...

[Mieze]

And that lnx2mac and slice's driver do not exhibit this problem...

Because they copy packets to/from a DMA buffer and let the network stack do most of the work...

 

Mieze