Jump to content

IntelMausiEthernet.kext for Intel onboard LAN


Mieze
1,015 posts in this topic

Recommended Posts

Quick question - has anyone had issues copying large (200 gig+) files using AFP since the 10.10.5 update? I've been trying to copy files to my server but after only 400-600 megs the ethernet link gets dropped and then reconnects after 4-5 seconds. After watching this happen a few times, I unmounted the server & reconnected using smb. 188.84 gigs into the transfer and no bad effects yet.

 

Thanks for any input!

crash

 

 

Edit: 214.75GB file just completed using smb - and not a single error...

Link to comment
Share on other sites

@chrashmaster4999: Please send me your complete kernel logs showing this issue. By the way, the fact that SMB works while AFP fails doesn't suggest a driver problem.

 

Mieze

Link to comment
Share on other sites

Hey Mieze, excellent work on this! Glad to see an extension with improved performance over the sometimes shaky E1000e kext/s in existence. 

 

Unfortunately haven't had much luck getting it to work -- booting gets to the point where the GUI should appear, and then my system reboots without error or warning. My board has both I211AT and I217V based controllers on board, so the first boot with your kext didn't seem to initialise any hardware at all (there is a boot log of the first boot here, if you would like to see it). 

 

I have since disabled the 211 controller (it isn't used anyway), along with network boot options and WoL options from within my UEFI settings... Now I can see that the 217 is being detected correctly, however the issue remains. Just as soon as the boot process should be presenting the GUI, my system reboots. 

 

The most recent boot log is posted for you here, though to my inexperienced eye it doesn't seem like there is any issue with the driver loading or anything that would seem to show a problem resulting in a reboot. Your knowledge is greater than mine, so I thought it best to post to ask. 

 

I'm running 10.10.5, and while I use Clover as a boot loader I have your kext in S/L/E manually (as this is just easier for me). I also don't have a DSDT. It's entirely possible that this is a local conflict with some other kext or application, and I do plan on doing a complete rebuild of my workstation when El Capitan launches and is stable enough for hackintoshing... It would just be great to get some improved networking happening in the mean time. FWIW, the I217V on my mainboard does work with an E1000e kext with the version number 3.2.4. 

 

Thanks a lot for your hard work! 

Link to comment
Share on other sites

@Andycore: Which board are you using?


Why not supported 

82567LM-2 ?

 

dev id: 0x10cc

I haven't removed the code supporting these old chips, only the device ID in the driver's Info.plist is missing. You might want to add your device ID and try if it works.

 

Mieze

Link to comment
Share on other sites

@Anycore: Provided your BIOS settings are correct and you don't have ncpi=0x2000 or npci=0x3000 among your kernel flags, there shouldn't be any problem because the driver is known to work stable in this configuration. If the issue persists, please search somewhere else.

 

Mieze

Link to comment
Share on other sites

I analyzed the issue RehabMan and others reported and was able to reproduce it on my test machine with an I218. According to my findings and the log data chrashmaster4999 sent me, the problem can be narrowed down to an interference of the way AFP organizes network buffers since 10.10.4 and a peculiarity of the chip's DMA engine.

 

After 25 hours of hard work it looks like I found a workaround which is working on my machine. I have successfully transferred 120GB of data over AFP without experiencing a single deadlock so that I'm quite confident that it will work on other machines too. Attached you'll find a prebuilt binary of the test version I've been using. Please test it thoroughly and report back if it works as expected.

 

Good luck!

 

Mieze

IntelMausiEthernet-2.0.2d3.zip

  • Like 2
Link to comment
Share on other sites

I analyzed the issue RehabMan and others reported and was able to reproduce it on my test machine with an I218. According to my findings and the log data chrashmaster4999 sent me, the problem can be narrowed down to an interference of the way AFP organizes network buffers since 10.10.4 and a peculiarity of the chip's DMA engine.

 

After 25 hours of hard work it looks like I found a workaround which is working on my machine. I have successfully transferred 120GB of data over AFP without experiencing a single deadlock so that I'm quite confident that it will work on other machines too. Attached you'll find a prebuilt binary of the test version I've been using. Please test it thoroughly and report back if it works as expected.

 

Good luck!

 

Mieze

Sorry I haven't had time to test lately (was away from my network for a while, now need to catch up).

 

Just a note though... my issue was with SMB, not AFP. Same fix you think?

Link to comment
Share on other sites

Sorry I haven't had time to test lately (was away from my network for a while, now need to catch up).

 

Just a note though... my issue was with SMB, not AFP. Same fix you think?

Probably yes as both, AFP and SMB, are based on TCP. The problem is that network buffers aren't physically contiguous and that the DMA engine seems to hang sometimes when a packet consists of multiple small data segments, in particular when it is a TSO operation. The first segment always contains the L2 - L4 headers which results in a size of 66 bytes. In the next segment there used to be the AFP/SMB header followed by the payload, but starting with 10.10.4 they seem to have separated the AFP/SMB header from the payload so that the second segment is small too (usually less than 100 bytes) resulting in two consecutive small segments.

 

I found out that there is a correlation between the selected descriptor handling policy and the probability of a deadlock and tried to find the most stable configuration empirically.

 

Mieze

Link to comment
Share on other sites

@Anycore: Provided your BIOS settings are correct and you don't have ncpi=0x2000 or npci=0x3000 among your kernel flags, there shouldn't be any problem because the driver is known to work stable in this configuration. If the issue persists, please search somewhere else.

 

Mieze

 

I'll have to continue troubleshooting on my end, though things don't look good. It is quite probably something I did initially setting up the machine, there have been several hardware changes since I initially installed OS X. 

 

Thank you for taking the time to check out the logs and offer your advice. I'll try again when I do a fresh install. 

Link to comment
Share on other sites

First, thanks for this driver, picked a cheap 82579V on ebay and both ports are recognized.

 

I do have a problem tho; I use one port as a 'jumbonet' -- I use a cat6 to a port in my linux machine, with jumbo frames, and traditionally use NFS over that.

 

The problem I'm having is that the link is not detected, most of the time... No amount of plugging/replugging works, you need to cold-reboot for the link to work (sometime). I've validated that it's not the other port of course, it definitely looks like it's this particular port combo.

 

When the link it there, it otherwise works beautifully..

 

I use v2.0.0d2

Link to comment
Share on other sites

First, thanks for this driver, picked a cheap 82579V on ebay and both ports are recognized.

 

I do have a problem tho; I use one port as a 'jumbonet' -- I use a cat6 to a port in my linux machine, with jumbo frames, and traditionally use NFS over that.

 

The problem I'm having is that the link is not detected, most of the time... No amount of plugging/replugging works, you need to cold-reboot for the link to work (sometime). I've validated that it's not the other port of course, it definitely looks like it's this particular port combo.

 

When the link it there, it otherwise works beautifully..

 

I use v2.0.0d2

 

There is something wrong with your problem description. First, the 82579V is a gigabit ethernet PHY which was designed to be combined with the 6 and 7 series chipset's integrated MAC as an onboard LAN solution. It is unsuitable for add-on cards. I don't know which chip you are using on your card, but it's definitely not a 82579V.

 

Second, the driver doesn't support jumbo frames because there is almost no performance advantage in real world scenarios and I see no good reason to implement it.

 

Mieze

Link to comment
Share on other sites

Hi !

 

First of all thanks for your great extension !!

I've installed the latest V2.0 in order to correct a problem I have with AppleIntelE1000e which is that my bandwidth isn't fully available.

Unfortunately I see the exact same shortcommings.

 

I have a GA-X79-UD7 with i7-3960X running at 4.5Ghz (OC'd with 1.25 strap). Running 10.10.5 with a full Clover install (latest version).

I tried removing the npci=0x2000 or npci=0x3000 flags, but my hack won't boot...

I theorically have a gigabit internet connexion, which I have tested and which normally gives me > 100 MBytes/s downloads.

What happens here is that when I do test downloads, I only get around ~10MB/s.

 

what made me suspect it could be a driver issue is that I tried every version of AppleIntelE1000e.kext I could find, and simply doing a kextunload/load of a different version

gives me different download speeds. I managed to get up to 80MB/s with version 2.4.14 but it hangs after a few seconds/minutes (I then need to do an ifconfig down/up to get it back).

 

here is a sample I just did with my hackintosh and with an old macbook on the same LAN :

me:

curl -o /dev/null http://test-debit.free.fr/image.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  647M  100  647M    0     0  9361k      0  0:01:10  0:01:10 --:--:-- 9616k

macbook:

curl -o /dev/null http://test-debit.free.fr/image.iso
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  647M  100  647M    0     0   101M      0  0:00:06  0:00:06 --:--:--  111M

can you feel the pain ? :)

 

The thing is, though, that I can get up to ~50-60 MB/s with aggregated sockets, ie when I download from usenet with many connexions.

But I get about half what I used to get, ie 50 instead of 100MB/s.

 

I installed your extension as you suggested (removed the E1000e, cache, reboot, new cache, config etc).

My system config (net.inet.xxx) shouldn't be the culprit, since I get very different bandwidth usage just by loading a different kext.

 

I'm at loss, and I don't know what to do. 

 

thanks for any suggestions you could offer ! :)

 

Link to comment
Share on other sites

here is the log extract, tell me if you need anything else. I'm a developer so I can try things, compile tests etc.

dmesg | grep Maus

Ethernet [IntelMausi]: TCP/IPv4 segmentation offload enabled.
Ethernet [IntelMausi]: TCP/IPv6 segmentation offload enabled.
Ethernet [IntelMausi]: TCP/IPv6 checksum offload enabled.
Ethernet [IntelMausi]: Version 2.0.0 using max interrupt rate 7000.
Ethernet [IntelMausi]: intrThrValue=557
Ethernet [IntelMausi]: PCI power management capabilities: 0xc822.
Ethernet [IntelMausi]: PME# from D3 (cold/hot) supported.
Ethernet [IntelMausi]: 82579V (Rev. 5) at 0xffffff81e99f5000, 50:e5:49:e0:eb:c1
Ethernet [IntelMausi]: MSI interrupt index: 0
Ethernet [IntelMausi]: kIOEthernetWakeOnMagicPacket added to filters.
Ethernet [IntelMausi]: Already in power state 1.
Ethernet [IntelMausi]: No medium selected. Falling back to autonegotiation.
Ethernet [IntelMausi]: checkLinkStatus() returned 1.
Ethernet [IntelMausi]: EEE mode = 0x0000, adv=0x0006, lpa=0x0000
Ethernet [IntelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control
Ethernet [IntelMausi]: CTRL=0x58100240
Ethernet [IntelMausi]: CTRL_EXT=0x195a1000
Ethernet [IntelMausi]: STATUS=0x40080083
Ethernet [IntelMausi]: GCR=0x00000000
Ethernet [IntelMausi]: GCR2=0x00000000
Ethernet [IntelMausi]: RCTL=0x04008002
Ethernet [IntelMausi]: PSRCTL=0x00040402
Ethernet [IntelMausi]: FCRTL=0x80005048
Ethernet [IntelMausi]: FCRTH=0x00005c20
Ethernet [IntelMausi]: RDLEN(0)=0x00002000
Ethernet [IntelMausi]: RDTR=0x00000000
Ethernet [IntelMausi]: RADV=0x00000000
Ethernet [IntelMausi]: RXCSUM=0x00002300
Ethernet [IntelMausi]: RFCTL=0x000380c0
Ethernet [IntelMausi]: RXDCTL(0)=0x00010000
Ethernet [IntelMausi]: RAL(0)=0xe049e550
Ethernet [IntelMausi]: RAH(0)=0x8000c1eb
Ethernet [IntelMausi]: MRQC=0x00370001
Ethernet [IntelMausi]: TARC(0)=0x0d800403
Ethernet [IntelMausi]: TCTL=0x3103f0fa
Ethernet [IntelMausi]: TXDCTL(0)=0x0141001f
Ethernet [IntelMausi]: TADV=0x0000001c
Ethernet [IntelMausi]: TIDV=0x0000001c
Ethernet [IntelMausi]: MANC=0x00000000
Ethernet [IntelMausi]: MANC2H=0x00000000

clover boot log :
7:226  0:000  LAN 0, Vendor=8086, MMIO=FB600000
23:068  0:000  LAN Controller [8086:1503] :: PcieRoot(0x0)\Pci(0x19,0x0)

ioreg :
    | |   +-o GBE@19  <class IOPCIDevice, id 0x10000022c, registered, matched, active, busy 0 (653 ms), retain 11>
    | |   | +-o IntelMausi  <class IntelMausi, id 0x100000509, !registered, !matched, active, busy 0 (0 ms), retain 7>
    | |   |   +-o en0  <class IOEthernetInterface, id 0x100000512, registered, matched, active, busy 0 (0 ms), retain 11>
    | |   |     +-o IONetworkStack  <class IONetworkStack, id 0x100000305, registered, matched, active, busy 0 (0 ms), retain 8>
    | |   |       +-o IONetworkStackUserClient  <class IONetworkStackUserClient, id 0x100000454, !registered, !matched, active, busy 0, retain 5>


--------------
tail -F /var/log/system.log |grep Mausi

# little after launching a curl speed test :
Aug 27 18:08:36 macpro kernel[0]: Ethernet [IntelMausi]: replaceOrCopyPacket() failed.

# nntp download with 40 connexions :
Aug 27 18:10:28 macpro kernel[0]: Ethernet [IntelMausi]: replaceOrCopyPacket() failed.



edit after doing some copy tests from and smb share : 

Aug 27 18:30:44 macpro kernel[0]: Ethernet [IntelMausi]: checkLinkStatus() returned 0.
Aug 27 18:30:44 macpro kernel[0]: Ethernet [IntelMausi]: Link down on en0
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: checkLinkStatus() returned 1.
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: EEE mode = 0x0000, adv=0x0006, lpa=0x0000
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: CTRL=0x58100240
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: CTRL_EXT=0x195a1000
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: STATUS=0x40080083
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: GCR=0x00000000
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: GCR2=0x00000000
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RCTL=0x04008002
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: PSRCTL=0x00040402
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: FCRTL=0x80005048
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: FCRTH=0x00005c20
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RDLEN(0)=0x00002000
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RDTR=0x00000000
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RADV=0x00000000
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RXCSUM=0x00002300
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RFCTL=0x000380c0
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RXDCTL(0)=0x00010000
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RAL(0)=0xe049e550
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: RAH(0)=0x8000c1eb
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: MRQC=0x00370001
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: TARC(0)=0x0d800403
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: TCTL=0x3103f0fa
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: TXDCTL(0)=0x0141001f
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: TADV=0x0000001c
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: TIDV=0x0000001c
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: MANC=0x00000000
Aug 27 18:30:48 Mac-mini kernel[0]: Ethernet [IntelMausi]: MANC2H=0x00000000
 
 

I attached my ioreg from IORegistryExplorer.

Mac mini.ioreg.zip

Link to comment
Share on other sites

@spaham: You are on the wrong track. The drivers are working fine. As you are a developer you should take a closer look at the internals of TCP and the parameters the kernel offers in order to optimize it.

 

Mieze

Link to comment
Share on other sites

@spaham: You are on the wrong track. The drivers are working fine. As you are a developer you should take a closer look at the internals of TCP and the parameters the kernel offers in order to optimize it.

 

Mieze

 

but if it's not the driver, can you tell me why doing the following has this effect :

- *without restarting*

- do a download test (even many times)

- average = 10M

- kextunload /.../E1000e.kext vx

- kextload /.../E1000e.kext vy

- download test

- average 80M (but hangs very quickly)

- (...)

- average 10M

- (...) 

 

I have tried many kernel parameters, and I'm quite savvy with them (I wrote BitsOnWheels, if you've heard of it, a native cocoa bittorrent client...) and they do not have any real impact on the limitation...

Link to comment
Share on other sites

but if it's not the driver, can you tell me why doing the following has this effect :

- *without restarting*

- do a download test (even many times)

- average = 10M

- kextunload /.../E1000e.kext vx

- kextload /.../E1000e.kext vy

- download test

- average 80M (but hangs very quickly)

- (...)

- average 10M

- (...) 

 

I have tried many kernel parameters, and I'm quite savvy with them (I wrote BitsOnWheels, if you've heard of it, a native cocoa bittorrent client...) and they do not have any real impact on the limitation...

Counterquestion: why and how do you relate this behavior to the driver? Why do you assume that it's behaving completely different each time you load it as this assumption makes no sense? When you are talking about your internet connection the influence of the driver on the timing is insignificant.

 

In the other hand parameters as the buffer size, delayed ack, etc. have a great influence on throughput. Besides that you shouldn't forget the congestion avoidance mechanism.

 

Mieze

Link to comment
Share on other sites

Counterquestion: why and how do you relate this behavior to the driver? Why do you assume that it's behaving completely different each time you load it as this assumption makes no sense? When you are talking about your internet connection the influence of the driver on the timing is insignificant.

sh-3.2# date;curl -o /dev/null http://test-debit.free.fr/image.iso
Jeu 27 aoû 2015 23:34:18 CEST
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 10  647M   10 66.5M    0     0  9892k      0  0:01:06  0:00:06  0:01:00 9611k^C
sh-3.2# kextunload /System/Library/Extensions/IntelMausiEthernet.kext/
sh-3.2# kextload /extras/nico\ kext/AppleIntelE1000e-v2.4.14/AppleIntelE1000e.kext
sh-3.2# date;curl -o /dev/null http://test-debit.free.fr/image.iso
Jeu 27 aoû 2015 23:35:58 CEST
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  647M  100  647M    0     0  96.1M      0  0:00:06  0:00:06 --:--:-- 96.4M
sh-3.2# kextunload /extras/nico\ kext/AppleIntelE1000e-v2.4.14/AppleIntelE1000e.kext
sh-3.2# kextload /System/Library/Extensions/IntelMausiEthernet.kext/
sh-3.2# date;curl -o /dev/null http://test-debit.free.fr/image.iso
Jeu 27 aoû 2015 23:36:48 CEST
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
 18  647M   18  122M    0     0  8824k      0  0:01:15  0:00:14  0:01:01 9053k^C
sh-3.2# 

edit : copy/paste problems :) 

Link to comment
Share on other sites

So far, so good, so what? Still no indication for a driver problem. Your test doesn't prove anything because there are too many parameters you don't have under control, in particular the packet roundtrip time and the influence of the packet scheduler. Looks more like the result of the congestion avoidance mechanism which reacts very sensitive on the roundtrip time and it's variation or QFQ which is one of the reasons why IntelMausiEthernet is stable.

 

Mieze

Link to comment
Share on other sites

So far, so good, so what? Still no indication for a driver problem. Your test doesn't prove anything because there are too many parameters you don't have under control, in particular the packet roundtrip time and the influence of the packet scheduler. Looks more like the result of the congestion avoidance mechanism which reacts very sensitive on the roundtrip time and it's variation or QFQ which is one of the reasons why IntelMausiEthernet is stable.

 

Mieze

 

Hummm ok, let's say you're right, what kind of kernel parameters would you play with then ?

I'd rather fix my problem than be right :)

 

(thanks for your time btw !! I hope I don't sound too cranky)

Link to comment
Share on other sites

Hummm ok, let's say you're right, what kind of kernel parameters would you play with then ?

I'd rather fix my problem than be right :)

 

(thanks for your time btw !! I hope I don't sound too cranky)

Frankly I'm not sure as there are things you can't control. The packet roundtrip time and it's variation are the factors which are used in order to detect congestion and it might easily produce false positives as both values are much higher for a remote connection which results in a dramatic slowdown. Basically it's a similar situation as with WIFI according to the IEEE802.11ac standard where the high roundtrip time is also a limiting factor and you might use the strategies used to optimize performance in these scenarios as a starting point.

 

The packet scheduler QFQ, which is a part of Apple's new driver interface, is something that is harder to influence but it is necessary in order to maintain stability under overload because it throttles the output rate when packets start to become bottled up in the output queue and prevents the network stack from dying due to the exhaustion of packet buffer memory. Comparison between versions 2.x.x of my drivers, which use QFQ, and versions 1.x.x, which use the traditional driver interface without packet scheduler, show that it might produce a significant performance hit in certain situations but it's necessary for a stable operation in some configurations, for example with virtualization software like VMware.

 

Mieze

  • Like 1
Link to comment
Share on other sites

Frankly I'm not sure as there are things you can't control.

 

Thanks for you help !

 

I found a "killer" solution : I bought a TP-LINK TG-3468 that worked Out Of the Box. (Well almost, since I had the AppleRTL8169Ethernet.kext already installed.)

I disabled my internal ethernet to make it easy for my link to be on en0 systematically.

 

And now I'm back with my >100MB/s data rates ! \o/

 

thanks for your time anyways :) 

 

(just for refs, I have a gigabyte GA-X79-UD7 rev1 running Yosemite 10.10.5).

Link to comment
Share on other sites

×
×
  • Create New...