Jump to content
Mieze

IntelMausiEthernet.kext for Intel onboard LAN

896 posts in this topic

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement

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...

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

@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

Share this post


Link to post
Share on other sites

@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 by tarasis

Share this post


Link to post
Share on other sites

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

 

:cat:

 

Mieze

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Mieze
      Being asked to add support for Realtek's Fast Ethernet PCIe NICs to my RTL8111 driver I got tired of answering the same old question again and again so that I finally decided to write a separate driver for these chips and to make a few of you guys and gals happy.
       
      As of now the driver supports the following members the RTL810X Fast Ethernet family:
      RTL8101E RTL8102E RTL8103E RTL8401E RTL8105E RTL8402 RTL8106E RTL8106EUS RTL8107E   Here is a list of the driver's basic features:
      Supports Sierra (maybe El Capitan). 64 bit architecture only. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). TCP segmentation offload under IPv4. Support for TCP/IPv6 and UDP/IPv6 checksum offload. Supports Wake on LAN. Support for Energy Efficient Ethernet (EEE) which can be disabled by setting enableEEE to NO in the drivers Info.plist without rebuild. The default is YES. The driver is published under GPLv2. Built using Xcode 4.6.3.  
      Changelog Version 2.0.1 (2018-05-10): Fixes a problem with retrieval of the permanent MAC address on some chips. Version 2.0.0 (2017-04-04): Uses Apple's private driver interface introduced with 10.8. Adds support for the RTL8107E. Supports packet scheduling with QFQ. Adds support for flow control and EEE. Version 1.0.0 (2014-05-24): First offical release.     Installation   Before you install the driver you have to remove any installed driver for RTL810X. Goto /S/L/E and delete the old driver. Recreate the kernel cache. Open System Preferences and delete the corresponding network interface, e. g. en0. If you forget this step you might experience strange problems with certain Apple domains, iTunes and iCloud later. Install the new driver and recreate the kernel cache. Reboot Open System Preferences again, select Network and check if the new network interface has been created automatically or create it manually now. Configure the interface.   Help - I'm getting kernel panics!
      Well, before you start complaining about bugs after you upgraded macOS and ask me to publish a driver update, you should first try to resolve the issue on your own by cleaning the system caches.
      As the driver uses macOS's private network driver interface, which is supposed to be used by Apple provided drivers only, you might run into problems after an OS update because the linker may fail to recognize that IONetworking.kext has been updated and that the driver needs to be linked against the new version (Apple provided drivers avoid this problem because they are always updated together with IONetworking.kext). As a result, the linking process produces garbage and the driver may call arbitrary code when trying to call functions from IONetworking.kext. This usually results in unpredicted behavior or a kernel panic. In order to recover from such a situation, you should clean the System Caches forcing the linker to recreate it's caches:
      Delete all the files in /System/Library/Caches and it's subdirectories but leave the directories and the symbolic links intact. This is very important! Reboot. Recreate the kernel cache. Reboot again.  
      Troubleshooting Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine. Use the debug version to collect log data when trying to track down problems. The kernel log messages can be retrieved with "grep kernel /var/log/system.log" in Terminal. Starting from Sierra use "log show --predicate "processID == 0" --debug" in order to retrieve kernel logs. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant. Don't copy and paste large amounts of log data to your post. Create an archive with the log data and attach it to your post. In case you don't want to make your log data publicly accessible, contact me via PM and I will provide you a mail address to send it directly to me.  Check your BIOS settings. You might want to disable Network Boot and the UEFI Network Stack as these can interfere with the driver. Double check that you have removed any other Realtek kext from your system because they could prevent the driver from working properly. Delete the following files: /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist /Library/Preferences/SystemConfiguration/preferences.plist Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000.  In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc. In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface. Use Wireshark to create a packet dump in order to collect diagnostic information. Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard, different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable.  
      Getting the driver
      There is a prebuilt binary in the Download section of this site: http://www.insanelymac.com/forum/files/file/259-realtekrtl8100-binary/ The source code can be found on Github: https://github.com/Mieze/RealtekRTL8100   Mieze
    • By Mieze
      A New Driver for Realtek RTL8111
       
      Due to the lack of an OS X driver that makes use of the advanced features of the Realtek RTL81111/8168 series I started a new project with the aim to create a state of the art driver that gets the most out of those NICs which can be found on virtually any cheap board on the market today. Based on Realtek's Linux driver (version 8.035.0) I have written a driver that is optimized for performance while making efficient use of system resources and keeping the CPU usage down under heavy load.

      Key Features of the Driver
      Supports Realtek RTL8111/8168 B/C/D/E/F/G found on recent boards. Support for multisegment packets relieving the network stack of unnecessary copy operations when assembling packets for transmission. No-copy receive and transmit. Only small packets are copied on reception because creating a copy is more efficient than allocating a new buffer. TCP, UDP and IPv4 checksum offload (receive and transmit). TCP segmentation offload under IPv4. Support for TCP/IPv6 and UDP/IPv6 checksum offload. Fully optimized for Mountain Lion (64bit architecture) but should work with Lion too. As of now there is no support for Snow Leopard but it can be added if someone will create the necessary patches. Supports Wake on LAN. Support for Energy Efficient Ethernet (EEE) which can be disabled by setting enableEEE to NO in the drivers Info.plist without rebuild. The default is YES. The driver is published under GPLv2.  
      Limitations
      As checksum offload doesn't work with jumbo frames they are currently unsupported and will definitely never be. No support for 32bit kernels.  
      Installation
      Before you install the driver you have to remove any installed driver for RTL8111/8168.
      Goto /S/L/E and delete the old driver (Lnx2mac, AppleRealtekRTL8169, etc.). Recreate the kernel cache. Open System Preferences and delete the corresponding network interface, e. g. en0. If you forget this step you might experience strange problems with certain Apple domains, iTunes and iCloud later. Reboot. Install the new driver and recreate the kernel cache. I recommend to use Kext Wizard or a similar utility for the installation. Reboot Open System Preferences again, select Network and check if the new network interface has been created automatically or create it manually now. Configure the interface.  
      Help - I'm getting kernel panics!
      Well, before you start complaining about bugs after you upgraded macOS and ask me to publish a driver update, you should first try to resolve the issue on your own by cleaning the system caches.
      As the driver uses macOS's private network driver interface, which is supposed to be used by Apple provided drivers only, you might run into problems after an OS update because the linker may fail to recognize that IONetworking.kext has been updated and that the driver needs to be linked against the new version (Apple provided drivers avoid this problem because they are always updated together with IONetworking.kext). As a result, the linking process produces garbage and the driver may call arbitrary code when trying to call functions from IONetworking.kext. This usually results in unpredicted behavior or a kernel panic. In order to recover from such a situation, you should clean the System Caches forcing the linker to recreate it's caches:
      Delete all the files in /System/Library/Caches and it's subdirectories but leave the directories and the symbolic links intact. This is very important! Reboot. Recreate the kernel cache. Reboot again.  
      Troubleshooting
      Make sure you have followed the installation instructions especially when you have issues with certain domains while the others are working fine. Use the debug version to collect log data when trying to track down problems. The kernel log messages can be found in /var/log/system.log. For Sierra and above use "log show --predicate "processID == 0" --debug" in order to retrieve kernel logs. Include the log data when asking for support or giving feedback. I'm an engineer, not a clairvoyant. Check your BIOS settings. You might want to disable Network Boot and the UEFI Network Stack as these can interfere with the driver. Double check that you have removed any other Realtek kext from your system because they could prevent the driver from working properly. Verify your bootloader configuration, in particular the kernel flags. Avoid using npci=0x2000 or npci=0x3000.  In Terminal run netstat -s in order to display network statistics. Carefully examine the data for any unusual activity like a high number of packets with bad IP header checksums, etc. In case auto-configuration of the link layer connection doesn't work it might be necessary to select the medium manually in System Preferences under Network for the interface. Use Wireshark to create a packet dump in order to collect diagnostic information. Keep in mind that there are many manufacturers of network equipment. Although Ethernet is an IEEE standard different implementations may show different behavior causing incompatibilities. In case you are having trouble try a different switch or a different cable.  
      FAQ
      How can I retrieve the kernel logs? In Terminal type "grep kernel /var/log/system.log". I want to disable Energy Efficient Ethernet (EEE) but I don't know how? Take a look at the driver's Info.plist file. There you will find an option named <key>enableEEE</key>. Change its value from <true/> to <false/>. Don't forget to recreate the kernel cache after changing the value. WoL from S5 doesn't work with this driver but under Windows it's working. Is this a driver bug? No it isn't, the driver is working as it should because OS X doesn't support WoL from S5.  
      Current status
      The driver has been successfully tested under 10.8.x and 10.9 with the B, C, D, E, F and G versions of the RTL8111/8168 and is known to work stable on these devices.  
      Changelog
      Version 2.2.2 (2018-01-21) Force ASPM state to disabled/enabled according to the config parameter setting. Requires 10.12 or newer. Version 2.2.1 (2016-03-12): Updated underlying linux sources from Realtek to 8.041.00. Added support for RTL8111H. Implemented Apple’s polled receive driver model (RXPOLL). Requires 10.11 or newer. Support for older versions of OS X has been dropped. Version 2.0.0 (2015-06-21): Uses Apple's private driver interface introduced with 10.8. Supports packet scheduling with QFQ. Please note that 2.0.0 is identical to 2.0.0d2. Only the version number has changed. Version 1.2.3 (2014-08-23): Reworked TSO4 and added support for TSO6. Version 1.2.2 (2014-08-44): Added an option to disable Active State Power Management (ASPM, default disabled) as ASPM seems to result in unstable operation of some chipsets. Resolved a problem with Link Aggregation after reboot. Added a workaround for the multicast filter bug of chipset 17 (RTL8111F) which prevented Bonjour from working properly Version 1.2.0 (2014-04-24): Updated underlying linux sources from Realtek to 8.037.00. Improved interrupt mitigate to use a less aggressive value for 10/100 MBit connections. Version 1.1.3 (2013-11-29): Improved transmit queue handling made it possible to reduce CPU load during packet transmission. Improved deadlock detection logic in order to avoid false positives due to lost interrupts. Version 1.1.2 (2013-08-03): Improved SMB performance in certain configurations. Faster browsing of large shares. Version 1.1.0 (2013-06-08): Support for TCP/IPv6 and UDP/IPv6 checksum offload added (can be disabled in Info.plist). Maximum size of the scatter-gather-list has been increased from 24 to 40 segments to resolve performance issues with TSO4 when offloading large packets which are highly fragmented. TSO4 can be disabled in Info.plist without rebuild. Statistics gathering has been improved to deliver more detailed information (resource shortages, transmitter resets, transmitter interrupt count). The interrupt mitigate settings has been changed to improve performance with SMB and to reduce CPU load. Configuration option added to allow for user defined interrupt mitigate settings without rebuild. Version 1.0.4 (2013-05-04): Moved setLinkStatus(kIONetworkLinkValid) from start() to enable(). Cleaned up getDescCommand(). Version 1.0.3 (2013-04-25): The issue after a reboot from Windows has been eliminated. Version 1.0.2 (2013-04-22): Added support for rx checksum offload of TCP and UDP over IPv6. Version 1.0.1 (2013-03-31): Improved behavior when rx checksum offload isn't working properly. Adds the chipset's model name to IORegistry so that it will show up in System Profiler.  
      Known Issues
      There are still performance problems with regard to SMB in certain configurations. My tests indicate that Apple's Broadcom driver shows the same behavior with those configurations. Obviously it's a more general problem that is not limited to my driver. WoL does not work in certain configurations. Old systems with 3 and 4 series chipsets exhibit performance issues in recent versions of macOS because there is no optimized power management for these systems in macOS anymore as Apple dropped support for the underlying hardware a long time ago. In case you are affected, please upgrade your hardware or find an alternative solution because I have no plans for a workaround. Sorry, but I don't think that it's worth the effort.  
      Getting the driver
      The source code can be found here: https://github.com/M...driver_for_OS_X There is also a pre-build binary for Mavericks and Yosemite: http://www.insanelym...n-and-wireless/  
      Building from Source
      I'm using XCode 4.6.3 for development. You can get a free copy of XCode after becoming a member of the Apple developer program. The free membership is sufficient in order to get access to development tools and documentation.
    • By End3rPower50
      Hi, i've installed on my pc MacOS Mojave but after installation my pc, sometimes, crash giving kernel panic.
      I came to the conclusion that it is a random kernel panic because sometimes it starting up and other times it isn't starting up
       
      My PC:
      CPU: Intel i7 6500U
      LAN: RTL8100
      Wi-Fi & Bluetooth: Dell DW1820A
      USB 3.1
       
      CLOVER.zip
    • By Angelo_
      Hi, I followed the rehabman guide (linked in the vanilla guide on the side of r/Hackintosh, not sure if I can link it) for laptops for my yoga 730ILW13 with an 8265u, Conexant 11870, 8gb of ram, 13.3" fhd and I found that upon booting the installer usb I get this weird issue where the screen displays what it should but the screen is incredibly dim (though it was off before using a flashlight on it) and it flashes every few seconds for a few milliseconds to the correct brightness, I used the plist for hd615-650 (including my 620), not quite sure what could be the culprit, first time hackintoshing a laptop so it might be a stupid brightness kext I forgot but didn't find any in that post or in this forum :c 
      Attached the clover zip so that anyone with more experience than me might give an idea in what could be a way to fix this.
      Thank you in advance 
       
       
       
      CLOVER.zip
    • By Bahaa
      Need help here
      My graphic card is detached 7mb
      and I try a lot of solution and no one work 
      can any one help
       

×