IntelMausiEthernet.kext for Intel onboard LAN

[Mieze]

Here is the latest development version of the driver. I also like to apologize for the delayed posting of the code but I'm a little bit overworked at the moment with not much time left for hackintoshing. As always, source code can be found on GitHub. Together with crashmaster4999 I've been investigation the randomly occurring tx deadlocks during the last weeks and I can now confirm that it is indeed a power management issue which can't be resolved inside the driver.

 

Ok, let's go into the details. As already mentioned, the real reason for the problems the driver is experiencing sometimes is the fact that the NIC's DMA operations may fail due to exceeded latency tolerance requirements when the CPU is in C7 sleep state. Most devices handle this in hardware using a standard PCIe mechanism to avoid problems but the Intel onboard NICs are different. See https://lwn.net/Articles/384146/ for an in deep explanation.

 

Unfortunately, El Capitan’s power management is quite aggressive, it tries to put the cores into the deepest sleep state C7 whenever possible and this is the reason why it became worse with El Capitan, in particular with powerful Core i7 CPUs because they spend much more time in a sleep state than a poor Core i3. I ran a few tests under Windows 10 on my machine and found out that it doesn’t use C7 at all. The deepest state the CPU ever reaches running Win 10 is C6 so that stable operation of the NIC is guaranteed. Unfortunately OS X never seems to put the CPU into C6, it only chooses between C3 and C7.

 

The SSDT-patch is obsolete now!

 

Mieze

IntelMausiEthernet-V2.1.0d3.kext.zip

Edited September 20, 2016 by Mieze

[giacomoleopardo]

• Using Clover to create the C-states seems to work better than using ssdtPRGen.sh because it uses higher values for the C-state exit lantencies.

 

You mean something like this in config.plist?

 

Still, C7 is present, though

[Mieze]

Yes, but it isn't that easy to get rid of C7. My knowledge about CPU power management is limited, I'm still learning too but even removing it from the SSDT doesn't prevent the CPU from entering C7. 

 

For detailed statistics of C-State residency every 5 seconds, open Terminal and type:

sudo powermetrics --hide-cpu-duty-cycle

Mieze

[vcn]

Hello,

 

Thank you a lot for your work. I have an Asus z170-a (I219V) and a 6700k.

I was getting crashes during large transfers so I installed the latest version of the driver and pached the SSDT created with ssdtPRGen.sh as you said.

 

My PStates look like this:

 

CPU Ratio Info:

------------------------------------

CPU Low Frequency Mode.............: 800 MHz

CPU Maximum non-Turbo Frequency....: 4000 MHz

CPU Maximum Turbo Frequency........: 4200 MHz

CPU P-States [ 36 (40) 42 ]

CPU C6-Cores [ 0 2 5 6 ]

CPU P-States [ 20 36 (40) 42 ]

CPU C6-Cores [ 0 1 2 4 5 6 7 ]

CPU P-States [ (16) 20 23 36 40 42 ]

CPU C6-Cores [ 0 1 2 3 4 5 6 7 ]

CPU P-States [ (14) 16 20 23 27 36 40 42 ]

 

After these changes I'm still getting the crashes with the same log info other users posted.

[Mieze]

@vcn: The SSDT patch I published is for Haswell CPUs only. I should have stated this explicitly. Unfortunately I don't know how to resolve the problem for Skylake CPUs because I'm not familiar with their power management details.

 

Mieze

[vcn]

Oh, ok. Anyway let me know if I can help testing something!

[tarasis]

Hi Mieze, do you think this will work with the dropping that I was getting? (I'm also running an i7-4790k with the Asus Z97-A board which uses I218V2 (Rev. 0)).

 

As a test I've dropped the patched dsdt.dsl with the tweaks you suggested long ago, I've generated a ssdt.aml with the tweaks you posted above, installed the new version of the driver and rebooted.

 

Running the power mode command my cpu never seems to hit C6

*** Processor usage ****

 

Intel energy model derived package power (CPUs+GT+SA): 12.35W

 

LLC flushed residency: 50.4%

 

System Average frequency as fraction of nominal: 98.25% (3926.92 Mhz)

Package 0 C-state residency: 53.86% (C2: 53.86% C3: 0.00% C6: 0.00% C7: 0.00% )

 

Performance Limited Due to:

CPU LIMIT IA_UTILIZATION

CPU LIMIT EDP_ICC

CPU LIMIT MAX_TURBO_LIMIT

CPU LIMIT TURBO_ATTEN

 

Core 0 C-state residency: 71.01% (C3: 2.41% C6: 0.00% C7: 68.59% )

CPU Average frequency as fraction of nominal: 93.95% (3755.32 Mhz)

CPU Average frequency as fraction of nominal: 99.68% (3984.32 Mhz)

 

Core 1 C-state residency: 76.80% (C3: 2.56% C6: 0.00% C7: 74.24% )

CPU Average frequency as fraction of nominal: 100.82% (4029.85 Mhz)

CPU Average frequency as fraction of nominal: 99.59% (3980.63 Mhz)

 

Core 2 C-state residency: 79.78% (C3: 3.02% C6: 0.00% C7: 76.76% )

CPU Average frequency as fraction of nominal: 99.85% (3991.03 Mhz)

CPU Average frequency as fraction of nominal: 99.29% (3968.75 Mhz)

 

Core 3 C-state residency: 79.22% (C3: 2.12% C6: 0.00% C7: 77.10% )

CPU Average frequency as fraction of nominal: 99.90% (3992.88 Mhz)

 

CPU Average frequency as fraction of nominal: 99.02% (3957.90 Mhz)

 

**** Processor usage ****

 

Intel energy model derived package power (CPUs+GT+SA): 3.53W

 

LLC flushed residency: 82.8%

 

System Average frequency as fraction of nominal: 76.92% (3074.64 Mhz)

Package 0 C-state residency: 84.77% (C2: 84.77% C3: 0.00% C6: 0.00% C7: 0.00% )

 

Performance Limited Due to:

CPU LIMIT IA_UTILIZATION

CPU LIMIT EDP_ICC

CPU LIMIT MAX_TURBO_LIMIT

 

Core 0 C-state residency: 90.77% (C3: 0.08% C6: 0.00% C7: 90.69% )

CPU Average frequency as fraction of nominal: 65.86% (2632.25 Mhz)

CPU Average frequency as fraction of nominal: 85.59% (3420.90 Mhz)

 

Core 1 C-state residency: 95.31% (C3: 0.11% C6: 0.00% C7: 95.19% )

CPU Average frequency as fraction of nominal: 80.52% (3218.56 Mhz)

CPU Average frequency as fraction of nominal: 86.43% (3454.50 Mhz)

 

Core 2 C-state residency: 95.06% (C3: 0.12% C6: 0.00% C7: 94.94% )

CPU Average frequency as fraction of nominal: 84.91% (3394.04 Mhz)

CPU Average frequency as fraction of nominal: 83.48% (3336.86 Mhz)

 

Core 3 C-state residency: 94.18% (C3: 0.33% C6: 0.00% C7: 93.85% )

CPU Average frequency as fraction of nominal: 84.03% (3358.63 Mhz)

CPU Average frequency as fraction of nominal: 82.47% (3296.31 Mhz)

[Mieze]

Hi Mieze, do you think this will work with the dropping that I was getting? (I'm also running an i7-4790k with the Asus Z97-A board which uses I218V2 (Rev. 0)).

 

As a test I've dropped the patched dsdt.dsl with the tweaks you suggested long ago, I've generated a ssdt.aml with the tweaks you posted above, installed the new version of the driver and rebooted.

 

Running the power mode command my cpu never seems to hit C6

Yeah, it's strange but it looks like OS X prefers putting the cores into C7 instead of C6 no matter what you do. I haven't managed to get rid of C7 completely but discouraging the CPU from entering that state seems to be enough for stable operation of the NIC.

 

Mieze

[Kiphaas7]

Hi Mieze, for some reason my intel I217LM controller is not even showing up in system report/ethernet cards. (Ethernet is part of the Asus Q87T mobo).

• network boot and UEFI network stack is disabled
• not running any of the npc bootflags 
• running the latest v2.1.0d3 from your posts, and placed it in EFI/CLOVER/kexts/10.11
• deleted my netwerk preferences multiple times
• deleted kext caches multiple times (using kext wizard)
• log from one boot up is attached. Kext seems to be loading, but exits with error:

Mar 27 00:42:36 localhost kernel[0]: Ethernet [IntelMausi]: maxSnoop: 0x0846, maxNoSnoop: 0x0000.

Mar 27 00:42:36 localhost kernel[0]: Ethernet [IntelMausi]: TCP/IPv4 segmentation offload enabled.

Mar 27 00:42:36 localhost kernel[0]: Ethernet [IntelMausi]: TCP/IPv6 segmentation offload enabled.

Mar 27 00:42:36 localhost kernel[0]: Ethernet [IntelMausi]: TCP/IPv6 checksum offload enabled.

Mar 27 00:42:36 localhost kernel[0]: Ethernet [IntelMausi]: Version 2.1.0d3 using max interrupt rate 7000. Please don't support tonymacx86.com!

Mar 27 00:42:36 localhost kernel[0]: Ethernet [IntelMausi]: intrThrValue=557

Mar 27 00:42:36 localhost kernel[0]: Ethernet [IntelMausi]: PCI power management capabilities: 0xc822.

Mar 27 00:42:36 localhost kernel[0]: Ethernet [IntelMausi]: PME# from D3 (cold/hot) supported.

Mar 27 00:42:36 localhost kernel[0]: Ethernet [IntelMausi]: Failed to get adapter data with error -2.

I'm at a loss why this isn't working...

test.log.zip

[Mieze]

@Kiphaas7: I've already seen this problem some time ago and I think that's it has got to do with the ME blocking access to the PHY due to enabled AMT. Have you tried to disable AMT in BIOS?

 

Mieze

[Kiphaas7]

@Kiphaas7: I've already seen this problem some time ago and I think that's it has got to do with the ME blocking access to the PHY due to enabled AMT. Have you tried to disable AMT in BIOS?

 

Mieze

Thanks for your quick reply! Unfortunately, that did not help. I just disabled AMT in BIOS and I still get the same IntelMausi messages in my system log.

[Kiphaas7]

Not sure if it will help, but I ran DPCIManager, and it does show my intel ethernet connection (see screenshot).

 

 

(For what it's worth, the Realtek shows up just fine with its third party kext.)

[Mieze]

Not sure if it will help, but I ran DPCIManager, and it does show my intel ethernet connection (see screenshot).

No, it doesn't help because the problem is that the driver can't access the NIC's PHY because the ME is still in control of it. That's why the initialization fails.

 

Mieze

[Kiphaas7]

After scouring the motherboard manual a few times, I did find a physical jumper related to Intel ME. However, setting that to disabled makes OS X unbootable, not even my usb stick I used to install.

 

Aside from that, can you nudge me in a direction how to fix this myself? Try different BIOS versions? DSDT fixes? Or is it pretty much unfixable?

[Kynyo]

Billion thanks for this great driver. I've just a problem, WOL doesen't activate after i shutdown my system. May be a driver issue? Because if I boot to Windows and shutdown the system after 2 seconds the RJ45 LED turn on.

[Mieze]

Billion thanks for this great driver. I've just a problem, WOL doesen't activate after i shutdown my system. May be a driver issue? Because if I boot to Windows and shutdown the system after 2 seconds the RJ45 LED turn on.

This is no driver bug, it's the specified behavior as OS X doesn't support WoL form S5.

 

Mieze

[Kynyo]

Curiously that in sleep mode (S3) it works.

[Mieze]

Curiously that in sleep mode (S3) it works.

Also nothing unusual, just the specified behavior.

 

Mieze

[Quadie]

...Ok, let's go into the details. As already mentioned, the real reason for the problems the driver is experiencing sometimes is the fact that the NIC's DMA operations may fail due to exceeded latency tolerance requirements when the CPU is in C7 sleep state. Most devices handle this in hardware using a standard PCIe mechanism to avoid problems but the Intel onboard NICs are different. See https://lwn.net/Articles/384146/ for an in deep explanation.

 

Unfortunately, El Capitan’s power management is quite aggressive, it tries to put the cores into the deepest sleep state C7 whenever possible and this is the reason why it became worse with El Capitan, in particular with powerful Core i7 CPUs because they spend much more time in a sleep state than a poor Core i3. I ran a few tests under Windows 10 on my machine and found out that it doesn’t use C7 at all. The deepest state the CPU ever reaches running Win 10 is C6 so that stable operation of the NIC is guaranteed. Unfortunately OS X never seems to put the CPU into C6, it only chooses between C3 and C7...

 

Are you sure about this?

 

More importantly are we talking Core States or Package States?  Under Windows 8, 8.1 and 10 my CPU cores (4790K) regularly hit C7 when idle/low load, but my package state only hits C3.

 

Also I remember reading somewhere (might have been a Intel doc) that the CPU will only drop into Package C7 if using the iGPU, else it will use Package C6.

[Mieze]

Are you sure about this?

 

More importantly are we talking Core States or Package States?  Under Windows 8, 8.1 and 10 my CPU cores (4790K) regularly hit C7 when idle/low load, but my package state only hits C3.

 

Also I remember reading somewhere (might have been a intel doc) that the CPU will only drop into Package C7 if using the iGPU, else it will use Package C6.

Yes, I am and I was talking about Core C-States as these are selected by OS directed power management according to the configuration in the SSDT whereas Package C-States are selected by the hardware itself whenever possible, provided they haven't been disabled completely.

 

By the way, Windows has a kernel API which allows drivers to communicate their latency requirements, which is something that OS X lacks.

 

Mieze

[Quadie]

Fair enough, I was just confused by you saying Windows will only hit C6.

 

Keep up the good work and stop by the hoob chat sometime.   

[magnifico]

hello mieze this kext support this chip ?

 

- 1 x Giga PHY Intel® I219V, 1 x GigaLAN Intel® I211AT

[Mieze]

 

hello mieze this kext support this chip ?

- 1 x Giga PHY Intel® I219V, 1 x GigaLAN Intel® I211AT

Please see post#1 of this thread for a list of supported chips.

 

Mieze

[magnifico]

Please see post#1 of this thread for a list of supported chips.

 

Mieze

 perfect 

[RehabMan]

There seems to be an issue with the latest as checked into github.

 

Hardware:

Intel NUCi5MYHE, identified as "I218LM3 (Rev. 3)" by IntelMausiEthernet.

 

Problem:

- network is non-functional after sleep/wake cycle

- detects cable but connects at 10-mbit instead of 1-gbit

- cannot get an ip address, eventually goes self-assigned

 

Problem happened at commit bff4c7a, "Version 2.1.0d0".  Problem does not exist at prior commit fca9762, "V2.0.2d7"

 

Let me know if you need/want debug logs in the bff4c7a failure case.

 

Note: TheRacerMaster fork which shows i219 support, fa2ac86, using Linux 3.2.6 sources, does not have this issue (on my i218 in the NUC).

 

Link to TheRacerMaster fork: https://github.com/theracermaster/IntelMausiEthernet/commits/master