IntelMausiEthernet.kext for Intel onboard LAN

[xiyue]

There is no need to make anything because you can use the debug version of the driver as it logs such events in detail. If there was a problem with link state detection, you should find some related log messages in the kernel logs when you plug/unplug the cable.

 

Mieze

 

@Mieze

I tried to trace the process of plug and unplugged cable and found that 'Cable Unplugged' is caused by the following code:

IntelMausiEthernet.cpp

....

bool IntelMausi::checkForDeadlock()

{

.

.

.

    if ((txDescDoneCount == txDescDoneLast) && (txNumFreeDesc < kNumTxDesc)) {        // <====This condition

        if (++deadlockWarn >= kTxDeadlockTreshhold) {

            mbuf_t m = txBufArray[txDirtyIndex].mbuf;

            UInt32 pktSize;

            UInt16 i, index;

            UInt16 stalledIndex = txDirtyIndex;

            //UInt8 data;

.

.

.

 

 

So I commented above code, the status of the interface is no longer toggle between 'Cable Unplugged' and 'Not Connected', but still can not send / receive data. It seems that the bottom cause is that the "initialization" process triggered by the plug of the network cable is not intact?

In addition, I found that let the laptop sleep and then wake up when the status of the interface toggle between 'Cable Unplugged' and 'Not Connected', the network will work fine.

[Mieze]

 

@Mieze

I tried to trace the process of plug and unplugged cable and found that 'Cable Unplugged' is caused by the following code:

IntelMausiEthernet.cpp

....

bool IntelMausi::checkForDeadlock()

{

.

.

.

    if ((txDescDoneCount == txDescDoneLast) && (txNumFreeDesc < kNumTxDesc)) {        // <====This condition

        if (++deadlockWarn >= kTxDeadlockTreshhold) {

            mbuf_t m = txBufArray[txDirtyIndex].mbuf;

            UInt32 pktSize;

            UInt16 i, index;

            UInt16 stalledIndex = txDirtyIndex;

            //UInt8 data;

.

.

.

 

 

So I commented above code, the status of the interface is no longer toggle between 'Cable Unplugged' and 'Not Connected', but still can not send / receive data. It seems that the bottom cause is that the "initialization" process triggered by the plug of the network cable is not intact?

In addition, I found that let the laptop sleep and then wake up when the status of the interface toggle between 'Cable Unplugged' and 'Not Connected', the network will work fine.

 

Just for your information: the code you commented out is part of the watchdog which causes a chip reset when packet transmission hangs. Really bad idea!

 

Mieze

[tcpMoniker]

Hey,

I have an Intel I219V2 Dual Ethernet board, the Gigabyte Z270N-WiFi. Using your driver, only one port works, both should work, as they aren't different chipsets, right?

 

I had a system cleanup courtesy of Pavo, and while trying to figure it out, my previous fix, which was basically, two kexts (AppleIGB), no longer works. IORegistryExplorer only shows en0. If I plug the cable in the other port and reboot into Windows, it's functional, in the chat they thought of network configuration issues and suggested an OS reinstall, also to clean everything up OS wise that may have been done, but from the first day I managed to boot with ethernet, the second port never worked. Any ideas on where to start looking? The lights at the back even light up, but no activity.

[Mieze]

Hey,

I have an Intel I219V2 Dual Ethernet board, the Gigabyte Z270N-WiFi. Using your driver, only one port works, both should work, as they aren't different chipsets, right?

 

I had a system cleanup courtesy of Pavo, and while trying to figure it out, my previous fix, which was basically, two kexts (AppleIGB), no longer works. IORegistryExplorer only shows en0. If I plug the cable in the other port and reboot into Windows, it's functional, in the chat they thought of network configuration issues and suggested an OS reinstall, also to clean everything up OS wise that may have been done, but from the first day I managed to boot with ethernet, the second port never worked. Any ideas on where to start looking? The lights at the back even light up, but no activity.

You are wrong, on your board there is only one I219V2 (two would be impossible) because it's just a PHY which is combined with the MAC integrated into the Z270 chipset and only this ethernet adapter is supported by the driver. The other NIC must be something else, for example an I210 or I211 which isn't supported. Sorry!

 

Mieze

[Pavo]

You are wrong, on your board there is only one I219V2 (two would be impossible) because it's just a PHY which is combined with the MAC integrated into the Z270 chipset and only this ethernet adapter is supported by the driver. The other NIC must be something else, for example an I210 or I211 which isn't supported. Sorry!

 

Mieze

Mieze actually his system only has Intel I219V2 with 2 physical ports, have looked at his system manual.

[Mieze]

Mieze actually his system only has Intel I219V2 with 2 physical ports, have looked at his system manual.

No, the manual is wrong because the chipsets only have 1 integrated MAC. It's impossible to build a board with two I219s.

 

Mieze

[Pavo]

Guess the only way to tell is look in windows and see what each ethernet port is.

[Mieze]

Guess the only way to tell is look in windows and see what each ethernet port is.

Please take a look at the chipset's datasheet and you will see that I'm right. I219 is not a full NIC but just a PHY which must be combined with the chipsets's integrated MAC and there is only one integrated MAC in the chipsets.

 

Mieze

[alladyn21]

Hi MaLd0n says maybe you can help me:

"u can post problem in Mieze's topic, She is amazin' and developed amazin' drivers.
I no have more idea. ;)"

alladyn21, on 23 Dec 2017 - 9:36 PM, said:
buu 
 
the same situation...
2017-12-23 21:34:17.980132+0100  localhost kernel[0]: (AppleACPIPlatform) Wake reason: PEG1 PEGP PEG2 PEGP PXSX RP10 PXSX RP11 PXSX RP12 PXSX RP13 PXSX RP02 PXSX RP04 PXSX RP05 PXSX RP06 PXSX RP07 PXSX RP08 PXSX P

When wol is off all is ok

I have z170 pro gaming and intel i210 in pecie because (onboard lan don't have wol in osx drivers) when wol is on (wake from pcie) pc itself wake up after a one second of sleep

[ITzTravelInTime]

Working perfectly using my sabertooth z87 and a managed gigabit switch, great driver, stable and optimized

[Mieze]

I have z170 pro gaming and intel i210 in pecie because (onboard lan don't have wol in osx drivers) when wol is on (wake from pcie) pc itself wake up after a one second of sleep

What exactly are you talking about? The onboard I219V or the I210 add-in card? Only the I219V is controlled by my driver while the I210 uses a native driver from Apple.

 

By the way, you should be aware of the fact that macOS only supports WoL from S3. WoL from S5 isn't supported at all and that's the reason why my driver doesn't support it. Also keep in mind that the wakeup event settings in BIOS refer to WoL from S5.

 

Mieze

[alladyn21]

So I will not be able to run the wol on i210 or the i219v ethernet card. It's just that the computer wakes up and I do not know why this is happening. If I turn off wol everything is ok. But when wol is on i dont have sleep.

So I will not be able to run the volt on one or the other ethernet card

[Mieze]

First of all, happy new year to all of you! I just wanted to let you know that I started to work on an update for the driver in order to support the Coffee Lake generation of I219.

 

Mieze

[Slice]

@Mieze

I encounter a problem with the driver v2.3.

When I send 1Gb file to another Mac by local LAN then the adapter stalls/freezes. I see internet stop working too.

Then I enter sleep and wake again. This helps and Safari works again.

So this is a problem with IntelMausi.

0:102  0:000  PCI (00|00:1F.06) : 8086 15B8 class=020000

What should I do? Make a dump?

[Mieze]

@Mieze

I encounter a problem with the driver v2.3.

When I send 1Gb file to another Mac by local LAN then the adapter stalls/freezes. I see internet stop working too.

Then I enter sleep and wake again. This helps and Safari works again.

So this is a problem with IntelMausi.

0:102  0:000  PCI (00|00:1F.06) : 8086 15B8 class=020000

What should I do? Make a dump?

Did you enable TSO? In case of yes, I know why it freezes because there is a well known hardware issue which causes trouble with OS X's transmit packet buffer layout.

 

Mieze

[Slice]

TSO? Thanks, will look on it and report a little later.

 

Have you a proposition why sleep/wake helps?

[Slice]

All is fine. I just has loaded 2.2 version from cache while 2.3 version was bad compiled (with 10.13SDK while I am on 10.12 system).

I recompiled 2.3 with 10.12SDK and copied 400Mb file during few seconds.

Great!

Ethernet [IntelMausi]: TCP/IPv4 segmentation offload disabled.
..
Ethernet [IntelMausi]: Link up on en0, 100-Megabit, Full-duplex, Rx/Tx flow-control

[xiyue]

First of all, happy new year to all of you! I just wanted to let you know that I started to work on an update for the driver in order to support the Coffee Lake generation of I219.

 

Mieze

Oh yeah, that's a good news, and I hope my problem will be repaired accidentally in this update.

[Mieze]

Anybody out there with a Coffee Lake hackintosh equipped with an I219 NIC who is willing to test the first development version 2.4.0d0 which adds support for Coffee Lake? In case you are interested, please send me a PM!

 

Mieze

[Mieze]

This is the first test build of version 2.4.0 of IntelMausiEthernet which updates the underlying Linux sources and adds official support for Coffee Lake. All users are encouraged to test it thoroughly. Although I tested it successfully on my I218V, you should keep in mind that this is work in progress which can't be expected to be 100% stable. In case things go wrong and you end up with a kernel panic, you should be prepared to recover your system from that situation.

 

Here is a short list of things to test:

1.) Boot

2.) IP address acquisition via DHCP.

3.) Cable unplug and replug. (Test several times!)

4.) Sleep/wake cycles (Test several times!).

 

In any case, please report back with attached kernel logs of the test run including the boot sequence. In case you need instructions how to retrieve them, please refer to post#1 of the driver's thread in the forum.

 

Good luck!

 

Mieze

IntelMausiEthernet-V2.4.0d0.zip

[hackaro]

 

Here is a short list of things to test:

1.) Boot

2.) IP address acquisition via DHCP.

3.) Cable unplug and replug. (Test several times!)

4.) Sleep/wake cycles (Test several times!).

 

 

 

Mieze

 

THANKS Mieze! As for now all the 4 points are working as expected here. Asus Z370 Prime A and i7-8700K. In case of malfunctioning I'll report back. 

 

Have a nice day 

[xiyue]

This is the first test build of version 2.4.0 of IntelMausiEthernet which updates the underlying Linux sources and adds official support for Coffee Lake. All users are encouraged to test it thoroughly. Although I tested it successfully on my I218V, you should keep in mind that this is work in progress which can't be expected to be 100% stable. In case things go wrong and you end up with a kernel panic, you should be prepared to recover your system from that situation.

 

Here is a short list of things to test:

1.) Boot

2.) IP address acquisition via DHCP.

3.) Cable unplug and replug. (Test several times!)

4.) Sleep/wake cycles (Test several times!).

 

In any case, please report back with attached kernel logs of the test run including the boot sequence. In case you need instructions how to retrieve them, please refer to post#1 of the driver's thread in the forum.

 

Good luck!

 

Mieze

     Yay! Well done! Really fulfilled my wish, accidentally solved my problem. 

    This version of the driver works fine on my laptop, and I tested it against the list you provided. every one passed. The attachment is a log of the startup process and the process of plug and unplug cable three times. There is a small detail, that is, plug the cable for the first time after boot, there will be a chance to Auto-negotiation in 10M full-duplex state.

    thanks again!

bootlog1.zip

[jrgieojvnviiwwi]

Hello Mieze and greetings from Austria :-) Thank you for developing your driver, I appreciate that I can just download drivers such as your kexts for free when you surely put quite some time into it.

 

Now I have a new mainboard with the new 300 coffee lake series, the Supero C7Z370-CG-L. It uses the i219 (v2) with device ID 0x15b8. Neither your 2.3.0 version nor your newest 2.4.0d0 works, unfortunately.

 

With both versions, the kext enables the NIC and recognizes when I plug in the network cable. But there is no actual connection, it does not receive an IP address via DHCP and when I configure the IP address settings manually, no connection can be established.

 

With Windows 10 on a second drive, the NIC works just fine. I tried unplugging and plugging in the cable several times. Furthermore I also tried the E1000 driver and the exact same behaviour occurs. Cable is recognized when connected, but no actual connection is established.

 

macOS autoconfigures to: 1000baseT, full-duplex, energy-efficient-ethernet, MTU Standard 1500. Playing around with those settings and reverting to 100Mbit/s does not change the behaviour.

 

Now I will try to figure out how to get the log files you asked for in your previous post about the 2.4.0d0 version and I'll write another post with the logs attached. I haven't checked them yet and I am not sure how to get them, yet.

 

Since the kext seems to respond to the device ID and macOS tries to use your kext for the NIC, I am afraid that maybe your driver just does not contain the code to run this NIC properly It's a very new mainboard and even though the i219v2 isn't such a new NIC, perhaps my mainboard has a new version of this NIC that isn't known yet?

 

I disabled the NIC in the UEFI, but the UEFI is a mess compared to Asus and Gigabyte, settings aren't explained at all (the user guide that comes with it does not contain them either, and that's supposed to be a professional supermicro product...) and so I am not sure if that is all done correctly. Perhaps I am missing a UEFI setting?

 

Thanks!

[Mieze]

Hello Mieze and greetings from Austria :-) Thank you for developing your driver, I appreciate that I can just download drivers such as your kexts for free when you surely put quite some time into it.

 

Now I have a new mainboard with the new 300 coffee lake series, the Supero C7Z370-CG-L. It uses the i219 (v2) with device ID 0x15b8. Neither your 2.3.0 version nor your newest 2.4.0d0 works, unfortunately.

 

With both versions, the kext enables the NIC and recognizes when I plug in the network cable. But there is no actual connection, it does not receive an IP address via DHCP and when I configure the IP address settings manually, no connection can be established.

 

With Windows 10 on a second drive, the NIC works just fine. I tried unplugging and plugging in the cable several times. Furthermore I also tried the E1000 driver and the exact same behaviour occurs. Cable is recognized when connected, but no actual connection is established.

 

macOS autoconfigures to: 1000baseT, full-duplex, energy-efficient-ethernet, MTU Standard 1500. Playing around with those settings and reverting to 100Mbit/s does not change the behaviour.

 

Now I will try to figure out how to get the log files you asked for in your previous post about the 2.4.0d0 version and I'll write another post with the logs attached. I haven't checked them yet and I am not sure how to get them, yet.

 

Since the kext seems to respond to the device ID and macOS tries to use your kext for the NIC, I am afraid that maybe your driver just does not contain the code to run this NIC properly It's a very new mainboard and even though the i219v2 isn't such a new NIC, perhaps my mainboard has a new version of this NIC that isn't known yet?

 

I disabled the NIC in the UEFI, but the UEFI is a mess compared to Asus and Gigabyte, settings aren't explained at all (the user guide that comes with it does not contain them either, and that's supposed to be a professional supermicro product...) and so I am not sure if that is all done correctly. Perhaps I am missing a UEFI setting?

 

Thanks!

According to the specs, there shouldn't be any problems with this chip. Get me the kernel logs with at least one complete boot sequence and we will se what's going on.

 

Mieze

[jrgieojvnviiwwi]

Thank you for the quick reply. Here is the log for "log show --predicate "processID == 0" --debug"

 

The ethernet cable was plugged in from the beginning, at around time 23:24:49 I unplugged it and at around 23:25:10 I plugged it in again.

 

I will look through the log now myself, but unless it's something trivial and especially if the driver itself needs a change, I'll surely need help. Thanks for your time!

logoneboot.txt