IntelMausiEthernet.kext for Intel onboard LAN

[wastez]

Over afp with Blackmagic Speedtest on my nas:

Read: 111,3 mb/s

Write: 109,9 mb/s

 

Edit:

smb is a little bit slower

Read: 109 mb/s

Write: 100 mb/s

[genzai]

Well i have some new very positive feedback to give on this driver.

While the hnak driver had worked decently well in almost all the situations i used it (later versions with high load disconnect problems aside) there was one situation where it continued to have major issues, even after rolling back to stable versions, etc- I never much got into diagnosing the culprit of the issues, but in this particular case when sharing a volume from a particular machine with the hank driver- a macbook pro connecting to it would have good write speeds (around 100mb) but really bad reads (only about 50mb). More importantly is the driver would stall and require a reboot (quite often) when reading heavily from the share (outgoing traffic). In any case i have now swapped in the Mausi driver on this system and both read and write speeds are now well over 100MB and there have been no driver crashes or disconnects as there had been on the hnak recent releases.

 

Bravo Mieze!

g\

 

PS, as an aside i have this working perfectly on 4 different systems and counting...

[Mieze]

I posted a new development release, version 1.0.0d3, a few minutes ago. You can find it attached to post #1 of this thread.

 

Good luck!

 

Mieze

[tarasis]

Installed the new version, and will monitor. Thank you for your continued work on the driver Mieze. 

[Mull7965]

Apologies if this is going off-topic. I installed the 1.0.0d2 version of the driver and ran it for a while. Didn't notice anything odd. However, when I looked at the output from netstat I realised that this driver doesn't seem to do checksums in software.

 

Output from "netstat -s" after using the system for a while with the hnak driver:

ip:
    238317 total packets received
        0 bad header checksums
        219647 headers (4393268 bytes) checksummed in software
        ...
    212038 packets sent from this host
        ...
        195009 headers (3900208 bytes) checksummed in software

Output after using the system for a while with the mausi driver (similar network usage profile):

ip:
    411934 total packets received
        0 bad header checksums
        0 headers (0 bytes) checksummed in software
        ...
    382249 packets sent from this host
        ...
        75 headers (1508 bytes) checksummed in software

Now, I do admit that I don't understand the details. My assumption is that headers that are not checksummed in software are checksummed in hardware in the NIC, right? Is it a good thing that the Mausi driver does almost no checksumming in software?

[Mieze]

Now, I do admit that I don't understand the details. My assumption is that headers that are not checksummed in software are checksummed in hardware in the NIC, right? Is it a good thing that the Mausi driver does almost no checksumming in software?

 

Checksum calculation is expensive, in particular when the NIC is operating at full speed, so that it's best to offload this task to the NIC whenever possible. Checksum insertion and verification is done in software only for packets which can't be checksummed by the NIC.

 

Mieze

[maleorderbride]

Thank you! Working well so far

[Riley Freeman]

Thanks for this new driver Mieze! Seems to be working fine in my Z68 (haven't really stressed it).

 

Can't try it on the X79 because of 10.6 but I don't use the ethernet on that as it's connected via wifi. It's the same 82579V anyway.

 

Update: Out of curiosity, I tried building it for 10.6. Got a few errors about kChecksumTCPIPv6 etc and found a post by RehabMan who had similar errors compiling your Realtek kext in 10.6. Used his hack (just the first step, no need for kernel detection as I built it solely for 10.6) and the kext compiled and loads fine on 10.6.8. I'll try wiring it up to something later and see if anything explodes.

[Mieze]

Update: Out of curiosity, I tried building it for 10.6. Got a few errors about kChecksumTCPIPv6 etc and found a post by RehabMan who had similar errors compiling your Realtek kext in 10.6. Used his hack (just the first step, no need for kernel detection as I built it solely for 10.6) and the kext compiled and loads fine on 10.6.8. I'll try wiring it up to something later and see if anything explodes.

 

In principle there is nothing except these constants which prevents the driver from building for 10.6 and I'm quite sure it will work on Snow Leopard too.

 

Mieze

[luxinhaus]

Update: Out of curiosity, I tried building it for 10.6. Got a few errors about kChecksumTCPIPv6 etc and found a post by RehabMan who had similar errors compiling your Realtek kext in 10.6. Used his hack (just the first step, no need for kernel detection as I built it solely for 10.6) and the kext compiled and loads fine on 10.6.8.

Can you explain please how you did it.. Thanks

[Riley Freeman]

Can you explain please how you did it.. Thanks

 

Here's the post from RehabMan I mentioned. I just added the contents of the first section of his hack to IntelMausiEthernet.cpp (at line 101 for reference, although that was just a random placement).

 

In Xcode (4.6.3 running on 10.7.5) I added the 10.6 SDK (taken from Xcode 4.2 for Snow Leopard) and set the Base SDK and Deployment Target in the Xcode project to 10.6.

[fffeee]

Something seems to go bananas sometimes and I can't figure out what the root cause is. One of the few clues I have to go on is IntelMausi's logging:

Feb 16 10:36:31 kernel[0]: Ethernet [IntelMausi]: Restart stalled queue!Feb 16 10:36:31 kernel[0]: Ethernet [IntelMausi]: Not enough descriptors. Stalling.
Feb 16 10:36:31 kernel[0]: Ethernet [IntelMausi]: Restart stalled queue!
Feb 16 10:36:32 kernel[0]: Ethernet [IntelMausi]: Not enough descriptors. Stalling.
Feb 16 10:36:32 kernel[0]: Ethernet [IntelMausi]: Restart stalled queue!
Feb 16 10:36:32 kernel[0]: Ethernet [IntelMausi]: Not enough descriptors. Stalling.

I've noticed that sometimes the intel ethernet device doesn't present itself at boot, which then results in the window server not starting correctly. I have no idea what difference that would make in loginwindow but when en0 doesn't come up I get a graphical display and a pointer on the screen but no loginwindow. I can login remotely via ssh (I have a second interface (AppleYukon)) and see only one device (en1 (AppleYukon)) has been configured. Usually a shutdown and then rebooting it resolves the issue but I also removed Cisco AnyConnect and purged a kernel extension on my Clover EFI directory for my old Marvell ethernet yesterday after a couple of boots without en0 showing up and I don't know if either of those were related or simply coincidence. 

 

I've just remotely issued a reboot again because when IntelMausi was logging this error my local zpool started erroring (!) so I had to quickly export the pool as much as I could and offline the storage, I raised some of the values for files and processes per uid for sysctl — fseventsd and spotlight are currently losing their minds and I'm not at home to force a reboot so hopefully the I/O situation sorts out and my reboot request gets handled before anything else happens.

[Mieze]

Something seems to go bananas sometimes and I can't figure out what the root cause is. One of the few clues I have to go on is IntelMausi's logging:

Feb 16 10:36:31 kernel[0]: Ethernet [IntelMausi]: Restart stalled queue!Feb 16 10:36:31 kernel[0]: Ethernet [IntelMausi]: Not enough descriptors. Stalling.
Feb 16 10:36:31 kernel[0]: Ethernet [IntelMausi]: Restart stalled queue!
Feb 16 10:36:32 kernel[0]: Ethernet [IntelMausi]: Not enough descriptors. Stalling.
Feb 16 10:36:32 kernel[0]: Ethernet [IntelMausi]: Restart stalled queue!
Feb 16 10:36:32 kernel[0]: Ethernet [IntelMausi]: Not enough descriptors. Stalling.

I've noticed that sometimes the intel ethernet device doesn't present itself at boot, which then results in the window server not starting correctly. I have no idea what difference that would make in loginwindow but when en0 doesn't come up I get a graphical display and a pointer on the screen but no loginwindow. I can login remotely via ssh (I have a second interface (AppleYukon)) and see only one device (en1 (AppleYukon)) has been configured. Usually a shutdown and then rebooting it resolves the issue but I also removed Cisco AnyConnect and purged a kernel extension on my Clover EFI directory for my old Marvell ethernet yesterday after a couple of boots without en0 showing up and I don't know if either of those were related or simply coincidence. 

 

I've just remotely issued a reboot again because when IntelMausi was logging this error my local zpool started erroring (!) so I had to quickly export the pool as much as I could and offline the storage, I raised some of the values for files and processes per uid for sysctl — fseventsd and spotlight are currently losing their minds and I'm not at home to force a reboot so hopefully the I/O situation sorts out and my reboot request gets handled before anything else happens.

 

I see no evidence for a driver issue. Looks more like a misconfigured system. The driver has to stall the output queue when resources become exhausted. Obviously something is flooding the network stack with packets. Are you using some kind of file sharing software?

 

Check the kernel logs to find out what prevents the network interface from coming up and what prevents the login window from appearing because the login window doesn't depend on en0.

 

Mieze

[tluck]

FYI... the d3 version has been working great for me over the last 5 days on my Lenovo T420. no worrisome messages.

 

saw the tx ring messages in the d2 version  - but have not seen these since i installed the d3 version

 

Feb 11 00:17:12 Toms-Mac kernel[0]: Ethernet [intelMausi]: Check tx ring for progress. txNumFreeDesc=2047

Feb 11 03:03:15 Toms-Mac kernel[0]: Ethernet [intelMausi]: Check tx ring for progress. txNumFreeDesc=2046

Feb 11 04:26:29 Toms-Mac kernel[0]: Ethernet [intelMausi]: Check tx ring for progress. txNumFreeDesc=2046

Feb 11 06:26:31 Toms-Mac kernel[0]: Ethernet [intelMausi]: Check tx ring for progress. txNumFreeDesc=2046

 

this is all i see now (upon reboot).

 

Feb 14 10:31:01 localhost kernel[0]: Ethernet [intelMausi]: TCP/IPv4 segmentation offload enabled.

Feb 14 10:31:01 localhost kernel[0]: Ethernet [intelMausi]: TCP/IPv6 segmentation offload enabled.

Feb 14 10:31:01 localhost kernel[0]: Ethernet [intelMausi]: TCP/IPv6 checksum offload enabled.

Feb 14 10:31:01 localhost kernel[0]: Ethernet [intelMausi]: Version 1.0.0d3 using max interrupt rate 7000.

Feb 14 10:31:01 localhost kernel[0]: Ethernet [intelMausi]: 82579LM (Rev. 4) at 0xffffff81089f5000, 00:21:cc:b5:5a:60

Feb 14 10:31:06 Toms-Mac kernel[0]: Ethernet [intelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control

[tarasis]

One thing I'm hitting occasionally is 

 

 

18/02/2015 01:25:28.000 kernel[0]: Ethernet [intelMausi]: Tx stalled? Resetting chipset. txDirtyDescIndex=209, IMS=0x80000080.

18/02/2015 01:25:28.000 kernel[0]: Ethernet [intelMausi]: Link down on en0

 

This time it occurred while I was loading my iTunes library from a Drobo (connected to a MacMini) over AFP and playing music, while at the same time running CoverScout (which is loading all the albums to detect missing covers). I've had it stutter playing the music and recover a couple of times, then it stopped. The traffic at the time was minimal (2-6MB/s) so its not that the link is saturated.

 

It also happened earlier this evening around when the screen went to sleep. (I left the computer for an hour, monitor sleep time set for 15 minutes, computer sleep time set to never) I had left iTunes open connected to a remote library, when I came back it was back to the local library. There was nothing useful in the log preceding it stalling.

17/02/2015 23:34:02.608 CallHistorySyncHelper[308]: notify name "ids-device-nearby-8868CB55-B857-401E-BF69-FC5AD23455F5" has been registered 40 times - this may be a leak
17/02/2015 23:34:02.608 CallHistorySyncHelper[308]: notify name "ids-device-nearby-064BF398-9BA8-4A3A-89FF-170DB57EB0D0" has been registered 40 times - this may be a leak
17/02/2015 23:34:15.000 kernel[0]: Ethernet [IntelMausi]: Tx stalled? Resetting chipset. txDirtyDescIndex=782, IMS=0x80000080.
17/02/2015 23:34:15.000 kernel[0]: Ethernet [IntelMausi]: Link down on en0
<snipped various services complaining that the link is gone>
17/02/2015 23:34:18.000 kernel[0]: Ethernet [IntelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control

Any thoughts?

[Mieze]

@tarasis: Use the debug version to collect more data and send me the kernel logs showing the problem. It should also include the driver startup sequence and when the link goes up. It might be a power management issue or an unstable connection.

 

Mieze

[tarasis]

@tarasis: Use the debug version to collect more data and send me the kernel logs showing the problem. It should also include the driver startup sequence and when the link goes up. It might be a power management issue or an unstable connection.

 

Mieze

 

Will do, thanks Mieze.

 

-- Edit

 

Running debug version now, but not had it repeat the error yet. Will keep an eye on it.

 

I am seeing this occasionally in the log:

Feb 18 14:54:58 MacPC kernel[0]: Ethernet [IntelMausi]: Not enough descriptors. Stalling.
Feb 18 14:54:58 MacPC kernel[0]: Ethernet [IntelMausi]: Restart stalled queue!

Edited February 18, 2015 by tarasis

[Mieze]

 

Will do, thanks Mieze.

 

-- Edit

 

Running debug version now, but not had it repeat the error yet. Will keep an eye on it.

 

I am seeing this occasionally in the log:

Feb 18 14:54:58 MacPC kernel[0]: Ethernet [IntelMausi]: Not enough descriptors. Stalling.
Feb 18 14:54:58 MacPC kernel[0]: Ethernet [IntelMausi]: Restart stalled queue!

 

This is harmless but it looks like something is flooding the output queue with packets. Are you using any kind of file sharing software or anything special?

 

You might also run ifconfig in Terminal and check if EEE is enabled. I've seen problems with tx deadlocks due to EEE with the Realtek driver sometimes and I wouldn't be surprised when Intel is affected too. EEE can be disabled selecting the medium manually in System Preferences.

 

Mieze

[tarasis]

I don't appear to have EEE enabled.

MacPC:docsgen rob$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	options=3<RXCSUM,TXCSUM>
	inet6 ::1 prefixlen 128 
	inet 127.0.0.1 netmask 0xff000000 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	nd6 options=1<PERFORMNUD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=6b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4,TSO6>
	ether <snip> 
	inet6 <snip>%en0 prefixlen 64 scopeid 0x4 
	inet 192.168.0.38 netmask 0xffffff00 broadcast 192.168.0.255
	nd6 options=1<PERFORMNUD>
	media: autoselect (1000baseT <full-duplex,flow-control>)
	status: active

As to sharing apps, the only two running are Dropbox and the OwnCloud app.

[tluck]

Mieze

- just i got the same thing tarisis reported on the 15th. happened last night.

 

the symptom is ethernet just stopped working.  so i ran sudo ifconfig en0 down ; sudo ifconfig en0 up 

it started working again. my gut is this may not be a driver issue - i.e. OSX stack issue? 

 

Feb 20 16:55:22 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 37 ResolverIntf:4

Feb 20 16:55:23 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 38 ResolverIntf:4

Feb 20 16:55:23 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 39 ResolverIntf:4

Feb 20 16:55:23 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 40 ResolverIntf:4

Feb 20 16:55:23 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 41 ResolverIntf:4

Feb 20 16:55:23 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 42 ResolverIntf:4

Feb 20 16:55:23 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 43 ResolverIntf:4

Feb 20 16:55:24 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 44 ResolverIntf:4

Feb 20 16:55:24 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 45 ResolverIntf:4

Feb 20 16:55:24 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 46 ResolverIntf:4

Feb 20 16:55:24 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 47 ResolverIntf:4

Feb 20 16:55:25 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 48 ResolverIntf:4

Feb 20 16:55:25 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 49 ResolverIntf:4

Feb 20 16:55:25 Toms-Mac.local discoveryd[54]: Basic DNSResolver UDNS Send(): UDP Sendto() failed to DNSNameServer 192.168.1.1 Port 53 errno 64, fd 86, ErrLogCount 50 ResolverIntf:4

Feb 20 16:55:36 Toms-Mac.local discoveryd[54]: Basic NATTServer Got control URL:  (ip)

Feb 20 16:55:52 --- last message repeated 1 time ---

Feb 20 16:55:52 Toms-Mac.local discoveryd[54]: Basic NATTServer,Warn connect failed 64 Host is down

Feb 20 16:56:08 Toms-Mac.local discoveryd[54]: Basic NATTServer Got control URL:  (ip)

Feb 20 16:56:29 --- last message repeated 1 time ---

Feb 20 16:56:29 Toms-Mac.local discoveryd[54]: Basic NATTServer,Warn connect failed 64 Host is down

Feb 20 16:56:44 Toms-Mac.local discoveryd[54]: Basic NATTServer Got control URL:  (ip)

Feb 20 16:56:49 Toms-Mac.local com.apple.iCloudHelper[2780]: AOSKit ERROR: Setup request failed, appleID=tjluckenbach@icloud.com, url=https://setup.icloud.com/setup/get_account_settings, requestHeaders=

{

    "Accept-Language" = "en-us";

    Authorization = "...";

    "X-APNS-Token" = ...;

    "X-Aos-Accept-Tos" = false;

    "X-Apple-ADSID" = "000022-05-32776fed-3b0b-4a38-8888-3257507fe1e9";

    "X-Mme-Client-Info" = "<MacBookPro8,1> <Mac OS X;10.10.3;14D72i> <com.apple.AOSKit/217 (com.apple.mail/8.2)>";

    "X-Mme-Country" = US;

    "X-Mme-Device-Id" = "80A91FC1-E94C-500E-91AD-EAABEC4E575A";

    "X-Mme-Timezone" = EST;

},

error=Error Domain=AOSErrorDomain Code=1000 "The operation couldn’t be completed. (AOSErrorDomain error 1000.)" UserInfo=0x7ff7eac0d9c0 {UnderlyingError=The request timed out., DialogInfo={

    DialogType = Unknown;

}}, httpStatusCode=-1, responseHeaders=

(null),

responseBody=

(null)

Feb 20 16:56:49 Toms-Mac.local com.apple.iCloudHelper[2780]: AOSKit ERROR: Failed to get mail props (doBypassCache=1, user=tjluckenbach@icloud.com, passwordProvided=0), accountInfoFound=0, mailDataclassInfo=

(null)

Feb 20 16:56:52 Toms-Mac.local discoveryd[54]: Basic NATTServer,Warn connect failed 64 Host is down

Feb 20 16:57:07 Toms-Mac.local discoveryd[54]: Basic NATTServer Got control URL:  (ip)

Feb 20 16:57:20 Toms-Mac.local Mail[3132]: AOSKit ERROR: XPC CLIENT: Connection [0x6000001f6c00] event handler received event with type: [XPC_TYPE_ERROR].  Description: [Connection interrupted]

Feb 20 16:57:20 Toms-Mac com.apple.iCloudHelper[3219]: objc[3219]: Class FALogging is implemented in both /System/Library/PrivateFrameworks/FamilyCircle.framework/Versions/A/FamilyCircle and /System/Library/PrivateFrameworks/FamilyNotification.framework/Versions/A/FamilyNotification. One of the two will be used. Which one is undefined.

Feb 20 16:57:20 Toms-Mac com.apple.xpc.launchd[1] (com.apple.imfoundation.IMRemoteURLConnectionAgent): The _DirtyJetsamMemoryLimit key is not available on this platform.

Feb 20 16:57:38 Toms-Mac.local discoveryd[54]: Basic NATTServer Got control URL:  (ip)

Feb 20 16:58:25 Toms-Mac.local discoveryd[54]: Basic NATTServer Got control URL:  (ip)

Feb 20 16:59:45 Toms-Mac.local discoveryd[54]: Basic NATTServer Got control URL:  (ip)

Feb 20 17:00:18 Toms-Mac.local ScreenSaverEngine[3220]: ### archList:(

    16777223

) --- 0

Feb 20 17:00:48 --- last message repeated 1 time ---

Feb 20 17:01:33 Toms-Mac.local discoveryd[54]: Basic DNSResolver  Re-Binding to random udp port 51844

Feb 20 17:02:08 Toms-Mac.local discoveryd[54]: Basic NATTServer Got control URL:  (ip)

Feb 20 17:02:56 Toms-Mac.local com.apple.iCloudHelper[3219]: AOSKit ERROR: Config request failed, url=https://setup.icloud.com/configurations/init, requestHeaders=

{

 

 

i looked through the log and network access things started going south around 16:15 and then apparently at 18:15 it then spit out these messages m

 

 

$ gzcat system.log.0.gz |grep -i ethernet

Feb 20 18:15:23 Toms-Mac kernel[0]: Ethernet [intelMausi]: Link down on en0

Feb 20 18:15:29 Toms-Mac kernel[0]: Ethernet [intelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control

Feb 20 18:15:43 Toms-Mac kernel[0]: Ethernet [intelMausi]: Tx stalled? Resetting chipset. txDirtyDescIndex=445, IMS=0x80000080.

Feb 20 18:15:43 Toms-Mac kernel[0]: Ethernet [intelMausi]: Link down on en0

Feb 20 18:15:48 Toms-Mac kernel[0]: Ethernet [intelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control

[Mieze]

i looked through the log and network access things started going south around 16:15 and then apparently at 18:15 it then spit out these messages m

 

 

$ gzcat system.log.0.gz |grep -i ethernet

Feb 20 18:15:23 Toms-Mac kernel[0]: Ethernet [intelMausi]: Link down on en0

Feb 20 18:15:29 Toms-Mac kernel[0]: Ethernet [intelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control

Feb 20 18:15:43 Toms-Mac kernel[0]: Ethernet [intelMausi]: Tx stalled? Resetting chipset. txDirtyDescIndex=445, IMS=0x80000080.

Feb 20 18:15:43 Toms-Mac kernel[0]: Ethernet [intelMausi]: Link down on en0

Feb 20 18:15:48 Toms-Mac kernel[0]: Ethernet [intelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control

 

Well, there are two incidents and at least the first one (16:55 h ) doesn't seem to be related to the driver at all as there are no driver messages.

 

The second (18:15h) is clearly a driver/ethernet issue. It looks like the negotiated link parameters didn't result in a stable connection which causes these link up/down cycles. Try to select the medium manually. I would suggest 1Gbit, no flow control, no EEE as this is the most basic setting.

 

Mieze

[wastez]

@ mieze

When do you plan to integrate WOL?

 

Would be really great to have it.

[Mieze]

When I

 

@ mieze

When do you plan to integrate WOL?

 

Would be really great to have it.

 

After all the teething troubles have been fixed, which have priority of course, I will need about a day of full time work to implement and test it. Basically it depends on the amount of spare time I have during the next weeks.

 

 

Mieze

[ludacrisvp]

Tested on Lenovo T440s w/ Intel I218LM (8086:155A)

No issues noted.

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=6b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4,TSO6>
ether 28:d2:44:b3:75:cd
inet6 fe80::2ad2:44ff:feb3:75cd%en0 prefixlen 64 scopeid 0x5
inet 10.10.10.110 netmask 0xffffff00 broadcast 10.10.10.255
nd6 options=1<PERFORMNUD>
media: autoselect (1000baseT <full-duplex,flow-control,energy-efficient-ethernet>)
status: active

I've not performed any performance testing so far but it seems to be working fine as a replacement for AppleIntelE1000e.kext

Feb 21 15:17:00 Eriks-MacBook-Air kernel[0]: Ethernet [IntelMausi]: TCP/IPv4 segmentation offload enabled.
Feb 21 15:17:00 Eriks-MacBook-Air kernel[0]: Ethernet [IntelMausi]: TCP/IPv6 segmentation offload enabled.
Feb 21 15:17:00 Eriks-MacBook-Air kernel[0]: Ethernet [IntelMausi]: TCP/IPv6 checksum offload enabled.
Feb 21 15:17:00 Eriks-MacBook-Air kernel[0]: Ethernet [IntelMausi]: Version 1.0.0d3 using max interrupt rate 7000.
Feb 21 15:17:01 Eriks-MacBook-Air kernel[0]: Ethernet [IntelMausi]: I218LM (Rev. 4) at 0xffffff81796a5000, 28:d2:44:b3:75:cd
Feb 21 15:17:44 Eriks-MacBook-Air kernel[0]: Ethernet [IntelMausi]: Link up on en0, 1-Gigabit, Full-duplex, Rx/Tx flow-control

 

[roh7]

Hi 

I just gave the driver a try 'cause of those big-data-transfer-problems with hnak's intel1000e.

 

Good news first: it works well, transfer speed is very good - but i got a weird problem: safari always crashes!

I rechecked it with i1000e re-installed (checked kextstat that the correct driver is loaded) no safari crash  - checked again with mausi-driver: safari crashed. Any other browser (firefox, chrome) did work...

 

I installed the driver on a yosemite 10.10.2 using "clover bootloader" on a Gigabyte H87 MB. Now I'd like to contribute to troubleshooting, but frankly I don't know how.

 

cheers

roh7