Jump to content

IntelMausiEthernet.kext for Intel onboard LAN


Mieze
1,015 posts in this topic

Recommended Posts

10 hours ago, Mieze said:

@Matgen84 You've probably got a messed up system which prevents the driver to be linked properly against IONetworking. kext. In order to resolve the issue, clean the system caches (this is not the same as the kernel cache, use the search function to find out how to do this) and, after that, recreate the kernel cache.

 

Mieze 

 

I only comment what @Kazlehoff said. I've got no problems with your great kext. For now I use 2.4.0 on Mojave.

Link to comment
Share on other sites

 

EDIT: *Nevermind* My network is performing flawlessly with 2.5.0d.  Turns out the SATA drive I was using was causing the issue.  I installed a NVME WD Black and my transfers are a steady 98-99MB/s with no system slow down.

 

Sorry for the false report, deleting the below info to avoid confusion for others.

 

Screen Shot 2019-02-26 at 8.55.04 PM.png

config.plist

Edited by Excitement
  • Thanks 1
Link to comment
Share on other sites

On 2/25/2019 at 11:31 AM, Matgen84 said:

A zip file is posted on this thread. 

for mojave. im on high sierra.

 

i got my ethernet issue solved on the new driver (seems to be happer on the EFI partition in efi/clover/other instead of /library/extensions

 

however, my issue is persisting. it may honestly be related to poster above me's issue... could we be looking at a particular issue with the z390 boards?

  • Sad 1
Link to comment
Share on other sites

On 2/26/2019 at 1:44 AM, pastrychef said:

Secondly, I have been using IntelMausiEthernet 2.5.0d for a few weeks and just realized that "Wake for network access" doesn't work with 2.5.0d.  Reverting back to 2.4.0 and it works perfectly.

I ran some tests with version 2.5.0d0 of the driver and I haven't noticed any problems with WoL. It works as expected. You might want to clean the system and kernel caches. In case a driver isn't linked properly, strange things may happen. I've also seen this many times.

  • Like 2
Link to comment
Share on other sites

1 hour ago, Mieze said:

I ran some tests with version 2.5.0d0 of the driver and I haven't noticed any problems with WoL. It works as expected. You might want to clean the system and kernel caches. In case a driver isn't linked properly, strange things may happen. I've also seen this many times.

 

Thanks.  I'll do more testing.

Link to comment
Share on other sites

11 hours ago, Mieze said:

I ran some tests with version 2.5.0d0 of the driver and I haven't noticed any problems with WoL. It works as expected. You might want to clean the system and kernel caches. In case a driver isn't linked properly, strange things may happen. I've also seen this many times.

 

Just to follow up, you were 100% correct...

sudo touch /System/Library/Extensions

sudo kextcache -i /

 

Fixed my WoL issue.  Thank you for your time and sorry for reporting a false bug.

 

Cheers!

  • Like 2
Link to comment
Share on other sites

  • 2 months later...
On 1/31/2015 at 1:26 AM, Mieze said:

On my dell optiplex 760, it does not work after the sleep connection to the internet I did not do everything as described ...:unsure:

 

Link to comment
Share on other sites

  • 1 month later...

Hello sir, I signed up on this website just to tell you : thank's.... 

 

I searched like 2 days to make ethernet work... with your kext and kbeast.. My ethernet worked with 3 min of work... Extract zip, install, reboot... 

 

Really, thank's it works perfect on I217V

Edited by fabien4455
  • Like 1
Link to comment
Share on other sites

Hello and thanks for this kext.

 

Currently I am using IntelMausiEthernet.kext v2.4 in /L/E with a Z370 chipset (Gigabyte Z370 Aorus Ultra Gaming WiFi) which has the Intel 1219v2 adapter. I have a system definition of 19,2 and am running High Sierra 10.13.6 (17G5019) . I have to boot with the -no_compat_check flag to get the system to boot with the 19,2 definition.

 

Today I connected to the internet for the first time with this rig. I plugged in the cable with the system off and booted. When the system came up, I opened the Network manager and found the system was connected. I did not have to do anything to set it up.

 

After confirming the connection, I opened Safari and checked a few things to make sure I had a good connection (browsed to a few sites). After I closed the Safari window, I did right click on the Safari icon to quit Safari. I have never liked the fact that MacOS leaves apps running in the background after you close out the window. Shortly after I quit Safari, the system suddenly restarted. I'm not sure if the events were related or not. I used it for a bit after the restart, mostly some browsing at iTunes, and it did not happen again. This has never happened before since I got things configured, but I have also never been on the internet.

Is it possible that this had something to do with IntelMausiEthernet.kext v2.4? Should I be using 2.5.0d0 with the 19,2 system definition?

I have also recently changed my system definition from 18,3 to 19,2 because I have an i7-8700k. The 19,2 definition doesn't like High Sierra, thus having to use the -no_compat_check flag to boot. It is possible the restart is related to the change in system definition but I thought I would check here because the shutdown happened after using the IntelMausiEthernet.kext for the first time.

 

I don't have XCode installed, so if someone could post a .zip with 2.5.0d0 compiled with the 10.13 target for High Sierra I would really appreciate that and could test if that makes a difference or not.

 

LMHmedchem

 

Link to comment
Share on other sites

  • 1 month later...

Here is version 2.5.0d14 of the driver in which I reworked interrupt throttling control and merged all the configuration parameters into one dictionary in order to make things clearer. The attached binary is for Mojave but it should be possible to use version 2.5.0d14 on Sierra and High Sierra provided you build from source. As usual, source code can be found on GitHub!

 

The most obvious change is the implementation of a completely new interrupt throttling control adding support for all of the NIC's interrupt throttling mechanisms and allowing to set different values for 1G, 100M and 10M mode. Here is a short summary of the new configuration parameters:

  • maxIntrRate10maxIntrRate100 and maxIntrRate1000 define independent global rate limits for all of the NIC's interrupts for the three different speeds. It's some kind of master control mechanism for interrupt throttling as all interrupts are subject to this parameter. These values define the maximum number of interrupts per second. For example maxIntrRate1000 = 8000 means that the number of interrupts caused per second by the NIC in gigabit mode  is not greater than 8000, i.e. that there is a time span of at least 125µs between two consecutive interrupts. Values between 2500 and 10000 are permissible. One might think that high interrupt rates result in better performance but this isn't always the case. Selecting extremely high values will seriously degrade system performance as well as network throughput. Choosing values which are too low, will also have a negative impact on network throughput.
  • rxDelayTime10rxDelayTime100 and rxDelayTime1000 control a timer which delays generation of a receive interrupt until the timer expires. The timer is started on reception of a packet. If another packed is received while the timer is running, it will be reinitialized to the start value allowing packet reception to be batched. Timer values are given in microseconds with a valid range of up to 100µs. A value of 0 or greater than 100 will disable this interrupt throttling method. Be careful when using this parameter as it might delay receive interrupts indefinitely if you don't set a hard limit for the delay using rxAbsTime10, rxAbsTime100 and rxAbsTime1000 which are described in the following section.
  • rxAbsTime10rxAbsTime100 and rxAbsTime1000 also control a timer which delays generation of a receive interrupt until the timer expires but unlike the former parameter the timer won't be restarted when another packet is received while it is running. This guarantees the generation of a receive interrupt after a definite timespan even in situations when rxDelayTime10, rxDelayTime100 or rxDelayTime1000 would suggest further delays because packets are received in a continuous sequence. Timer values are given in microseconds with a valid range of up to 500µs. A value of 0 or greater than 500 will disable this interrupt throttling method.

Values chosen in the default configuration are based on speed tests I performed with Blackmagic Disk Speed Test over a SMB connection to my server. In most scenarios there shouldn't be any need for changes but you might want to adjust these settings in case you have an unusual network setup like gigabit WAN and experience problems exhausting available bandwidth.

 

 All users are encouraged to test the driver on their system. Good luck!

 

Mieze :cat:

 

IntelMausiEthernet-V2.5.0d14.kext.zip

Edited by Mieze
  • Like 6
Link to comment
Share on other sites

  • 2 weeks later...

hi, mieze thanks a lot for the driver,

my build is

gigabyte Z390 M(not gaming)

i5 9400F

AMD RX 560

I installed Sierra on my PC and everything works perfectly except for the network, I installed the above driver that you have attached, but not working.

I downloaded Xcode and also the project from Github, how exactly should I build it for sierra, as I am no familiar with Xcode. Please tell me the instructions on how to do it!

help me out this noob! 

thanks a lot!

Link to comment
Share on other sites

In case you want to built for an older version of macOS, you'll have to use the corresponding version of Xcode which includes the SDK for that OS and select that OS version as deployment target.

Edited by Mieze
Link to comment
Share on other sites

2 minutes ago, ellaosx said:

I believe this is not an error, but only a warning. 

You are right and it should work this way too but it's usually best to use the matching SDK. Since Apple adopted this update or die mentality, they don't care for backward compatibility anymore.

  • Like 1
Link to comment
Share on other sites

1 hour ago, Mieze said:

In case you want to built for an older version of macOS, you'll have to use the corresponding version of Xcode which includes the SDK for that OS and select that OS version as deployment target.

But I use Xcode 9.2, which fully supports sierra but it still shows me this warning!

help me out!

 

 

Link to comment
Share on other sites

 

 
 
 
 
15 minutes ago, Mieze said:

Chose "Clean" from the menu "Products".

I pressed cmd+shift+k and it showed me that it has been cleaned successfully.

After a while, I selected the build option but still, I get this same warning again.

build or newer osx version.

Link to comment
Share on other sites

  • 2 weeks later...

@Mieze I noticed that @vit9696 has forked and made a copy of your kext.  I've seen that some of your commits were also pulled into that new repo.  I'm currently using your latest debug driver, as it works great with 10.14.6 but I was wondering which you recommend to use going forward?  Will the acidanthera version be the one to use going forward?

Edited by CoBrA2168
Link to comment
Share on other sites

×
×
  • Create New...