Jump to content
  • Announcements

    • Allan

      Forum Rules   04/13/2018

      Hello folks! As some things are being fixed, we'll keep you updated. Per hour the Forum Rules don't have a dedicated "Tab", so here is the place that we have our Rules back. New Users Lounge > [READ] - InsanelyMac Forum Rules - The InsanelyMac Staff Team. 
hnak

AppleIntelE1000e.kext for 10.8/10.7/10.6/10.5

767 posts in this topic

Recommended Posts

Back on Yosemite with the same symptoms I reported earlier in the thread, a few pages back: sending large amounts of data over ipv6 crowbars the ethernet interface under this driver.

 

I checked but there doesn't seem to be a newer one than 3.1.0. I tried installing mieze's fixed version that worked for me on Mavericks, but afraid it's no longer making a difference. Currently my fix is to run VMWare (which for other reasons I no longer have to do all the time for other reasons).

 

Also slightly annoyed with myself: Decided sod it and bought a Realtek RTL8111E-based PCIe card, from a supplier who always dispatches very quickly - too quickly, they'd dispatched it before I remembered I didn't have a spare slot for it in my (mini-itx) hackintosh machine. Daft me...

 

(Mind you I would if the displayport-crash-on-wake problem on my HD4600 was fixed, but that's another story... :-} )

 

A revised version would be really great, so that IPv4 TSO is working on some devices too.

So maybe somebody has some time to have a look on it.

Share this post


Link to post
Share on other sites

Hey everyone, interesting problem with the E1000E.kext 3.1.0 and OS X 10.9/10.10. I have an i217 ethernet chipset, motherboard is Z97X-SLI. Using clover bootloader. Hoping someone can shed some light:

 

WOL works on sleep and shutdown BUT if the computer has been to sleep and is THEN shutdown, WOL no longer works. Problem does not happen in Windows 7. Happened in both 10.9 and 10.10.

 

Can provide any pertinent details if anyone has any idea at all. Anyway HNAK thanks for the awesome driver and hoping this is either a known issue or something easy to fix. Cheers.

Share this post


Link to post
Share on other sites

Hey everyone, interesting problem with the E1000E.kext 3.1.0 and OS X 10.9/10.10. I have an i217 ethernet chipset, motherboard is Z97X-SLI. Using clover bootloader. Hoping someone can shed some light:

 

WOL works on sleep and shutdown BUT if the computer has been to sleep and is THEN shutdown, WOL no longer works. Problem does not happen in Windows 7. Happened in both 10.9 and 10.10.

 

Can provide any pertinent details if anyone has any idea at all. Anyway HNAK thanks for the awesome driver and hoping this is either a known issue or something easy to fix. Cheers.

The driver knows nothing about the way it is shutdown. It just expects disable/stop invocation at shutdown and start/enable at power-on.

I have no information for driver writers other than ordinary published documents ... almost nothing.

Share this post


Link to post
Share on other sites

The driver knows nothing about the way it is shutdown. It just expects disable/stop invocation at shutdown and start/enable at power-on.

I have no information for driver writers other than ordinary published documents ... almost nothing.

Hmm... so any clue as to what might be the cause of the issue? To reiterate, if I boot and shut down, WOL works. If I boot and sleep, WOL works. If I sleep more times, WOL will wake from sleep. But if the system is shutdown after a sleep has occured (whether woken by WOL or not), wake on lan is not enabled on that shutdown. Could it be an issue with Clover? Any hints would be much appreciated. Thanks for the wisdom folks.

Share this post


Link to post
Share on other sites

Hmm... so any clue as to what might be the cause of the issue? To reiterate, if I boot and shut down, WOL works. If I boot and sleep, WOL works. If I sleep more times, WOL will wake from sleep. But if the system is shutdown after a sleep has occured (whether woken by WOL or not), wake on lan is not enabled on that shutdown. Could it be an issue with Clover? Any hints would be much appreciated. Thanks for the wisdom folks.

 

This is not a bug, it's the normal behavior because OS X doesn't support WoL from S5 and Clover has absolutely nothing to do with it. Just to go through all the steps again:

  • When the system is going to sleep (S3):
  1. The driver's setWakeOnMagicPacket() function is called to enable WoL in case the user has enabled it in System Preferences.
  2. disable() is called.
  3. setPowerState() is called to put the device into power state D3.
  • On wakeup the calling sequence to get back to S0 is:
  1. setPowerState() is called to restore D0 power state.
  2. enable() is called.
  3. The driver's setWakeOnMagicPacket() function is called to disable WoL.
  • When the system is shut down (going to enter S5) or rebooted:
  1. The network stack will call the driver's systemWillShutdown() function. The driver is responsible to take the required actions to prepare the device for a reset or shutdown, usually by calling disable() internally. Note that neither disable() nor stop() is called by the network stack itself in this situation.

There is no way to tell the driver to enable WoL from S5 in case of a shutdown. 

 

Mieze

Share this post


Link to post
Share on other sites

because OS X doesn't support WoL from S5...

 

...There is no way to tell the driver to enable WoL from S5 in case of a shutdown. 

 

 

Thanks for the reply - however I don't believe that is true. On previous builds (using 10.6-10.8) WoL worked perfectly fine from S5. Even on this build, WoL works from S5 from OS X unless it has first entered S3 on that boot. That is the source of my problem - clearly entering S3 changes something so that upon waking and subsequently entering S5 the NIC no longer listens for a magic packet. 

 

That is what has me thinking it is either a driver or Clover problem...

 

Please forgive me if there is something basic I'm not understanding; I've never written a driver before. But WoL from S5 does work, and in a previous build with a realtek card (using Lnx2Mac's driver) it worked from S5 after the system had resumed from S3 as well. 

Share this post


Link to post
Share on other sites

Thanks for the reply - however I don't believe that is true. On previous builds (using 10.6-10.8) WoL worked perfectly fine from S5. Even on this build, WoL works from S5 from OS X unless it has first entered S3 on that boot. That is the source of my problem - clearly entering S3 changes something so that upon waking and subsequently entering S5 the NIC no longer listens for a magic packet. 

 

That is what has me thinking it is either a driver or Clover problem...

 

Please forgive me if there is something basic I'm not understanding; I've never written a driver before. But WoL from S5 does work, and in a previous build with a realtek card (using Lnx2Mac's driver) it worked from S5 after the system had resumed from S3 as well. 

 

Once again, Clover has absolutely nothing to do with it, because it doesn't touch the NIC in any way!

 

If WoL from S5 was working properly in pervious versions, it must have been a bug or pure coincidence, for example because it was enabled after reset (by the BIOS?) and the driver didn't change the settings. Anyway, enabling WoL from S5 is not the specified behavior under OS X and doing so would mean that there would be no way to disabled it.

 

Mieze

Share this post


Link to post
Share on other sites

Once again, Clover has absolutely nothing to do with it, because it doesn't touch the NIC in any way!

 

If WoL from S5 was working properly in pervious versions, it must have been a bug or pure coincidence, for example because it was enabled after reset (by the BIOS?) and the driver didn't change the settings. Anyway, enabling WoL from S5 is not the specified behavior under OS X and doing so would mean that there would be no way to disabled it.

 

Mieze

I'd say it was probably the driver doing nothing, as you suggest, and my BIOS handling everything. I simply unchecked "wake on magic packet" in the energy saver control panel, and everything works. WoL from S5, S3, and S5 after S3 all work now. So having the driver play no role in WoL seems to be working.

 

Hope this solution might help someone else in the same spot. 

Share this post


Link to post
Share on other sites

I'm also using the AppleIntelE1000e.kext at version 3.1.0 and network speeds have gone from +100MB/s on file transfers from/to the NAS to 31MB/s and if i try to benchmark the network speeds, the card hangs completely with kernel[0]: AppleIntelE1000e(Err): Detected Hardware Unit Hang.

 

Anyone know any solution to the issue?

 

Using latest OS X Yosemite by the way.

Share this post


Link to post
Share on other sites

I'm also using the AppleIntelE1000e.kext at version 3.1.0 and network speeds have gone from +100MB/s on file transfers from/to the NAS to 31MB/s and if i try to benchmark the network speeds, the card hangs completely with kernel[0]: AppleIntelE1000e(Err): Detected Hardware Unit Hang.

 

Anyone know any solution to the issue?

 

Using latest OS X Yosemite by the way.

 

Well I solved it by buying real network card. I went with one based on the Realtek 8111E chipset which uses the rock solid stable Realtek8111 driver available on here. I get my full 100MB/s I should get with that driver and have literally in the last week copied around 10TiB of data at that speed re-arranging/organizing my files on my various machines. If you have one of the intel 217 or similar series and you search on that and problems linux you will see pages of flakyness reported, IIRC this driver is based on that code so the problems have carried over.

Share this post


Link to post
Share on other sites

Hey everyone, i met similar problems with the E1000E.kext 3.1.0 and 10.10 like Himlaklar.

I have an i217v ethernet chipset, motherboard is Gigabyte B85N-WIFI.

Network speeds have gone from +114MB/s on file transfers from/to the NAS to 10-40MB/s,

There were lots of kernel messages like kernel[0]: e1000_tx_map: failed to getphysicalsegment.

Temporary workaroud is disable NETIF_F_TSO in info.plist which bump tx speed to around 100MB/s, still can't match rx speed while windows driver has no problem。

hnak, Mieze, is there a fix for this?

Share this post


Link to post
Share on other sites

I actually bought a Realtek 8111E chipset network card, but it too shuts off if i transfer large filers form the NAS.

 

Going into sleep then waking the computer up again, seems to work, but it is SO annoying.

Share this post


Link to post
Share on other sites

I actually bought a Realtek 8111E chipset network card, but it too shuts off if i transfer large filers form the NAS.

 

Going into sleep then waking the computer up again, seems to work, but it is SO annoying.

 

I did the same and found the same; big tx out via the Realtek seemed to intermittently crash the network stack; reboot required to get out of it (though I didn't try sleep/wake - suspect that wouldn't work for me because I have unrelated display/sleep/wake issues with my displayport on hd4600 that would probably be triggered by trying an actual whole-machine sleep too.)

 

Suspecting, but not knowing, that it's IPv6, I've started explicitly mounting nfs and ssh/rsyncing with IPv4. If it happens again, it's not that. :-)

 

I also haven't been running vmware anything like as much as i used to; but running vmware (even with no vms running) had a protective effect on the e1000. not sure that pattern holds on the realtek.

heh. Sometimes I think, sod it I'll just get a real mac - not that I don't have several, but to match the spec of the hackintosh, that's over £2K...

 

And what if the same problem still arises because it's actually a bug at a completely different level? After all, it's arising on two different network cards with drivers written by two different people here - and frankly there's more chance of a bugfix from these guys if it's something in their purview; submitting a bug report to Apple is like dropping something into a black hole. No information escapes...

Share this post


Link to post
Share on other sites

...

 

heh. Sometimes I think, sod it I'll just get a real mac - not that I don't have several, but to match the spec of the hackintosh, that's over £2K...

 

And what if the same problem still arises because it's actually a bug at a completely different level? After all, it's arising on two different network cards with drivers written by two different people here - and frankly there's more chance of a bugfix from these guys if it's something in their purview; submitting a bug report to Apple is like dropping something into a black hole. No information escapes...

Over at tonymac86 someone reports that it happens on real Mac's as well, but only if they are wired. WiFi seems to work just fine.

Share this post


Link to post
Share on other sites

@Himlakar & StrangeNoises: Are you using Yosemite?

 

Mieze

yes

 

fwiw RealTekRTL8111.kext 1.2.3. Card identifies as a RTL8186E/8111E vendor/device 10EC/8186. And for the most part works great; I just had that glitch yesterday (repeated over several reboots) where trying to send files to another machine resulted in network hanging as previously experienced on the mainboard card.

 

The AppleIntelE1000e.kext 3.1.0 is also still installed and presumably loaded (shows on System Profile/Ethernet cards), but the ethernet lead isn't plugged into that.

Share this post


Link to post
Share on other sites

Well, I think that Yosemite's network stack is broken and causes all those problems when it gets under load. That's why I'm staying with Mavericks until they manage to fix the issue. As of now there is only one solution: get back to Mavericks!

 

Mieze

Share this post


Link to post
Share on other sites

yes

 

fwiw RealTekRTL8111.kext 1.2.3. Card identifies as a RTL8186E/8111E vendor/device 10EC/8186. And for the most part works great; I just had that glitch yesterday (repeated over several reboots) where trying to send files to another machine resulted in network hanging as previously experienced on the mainboard card.

 

The AppleIntelE1000e.kext 3.1.0 is also still installed and presumably loaded (shows on System Profile/Ethernet cards), but the ethernet lead isn't plugged into that.

 

Mine has the same vendor/device 10EC/8186 revision id 0006 card identifies as a RTL8186E-VL/8111E-VL under Mavericks. As I mention above rock solid stable under that OS and always has been, I would go into the BIOS and disable the on-board nic. I always do that for devices not in use just to eliminate any possible problems by leaving them enabled. BTW Mieze thanks again for this absolutely great driver you have made for us to use.

Share this post


Link to post
Share on other sites

Well, I think that Yosemite's network stack is broken and causes all those problems when it gets under load. That's why I'm staying with Mavericks until they manage to fix the issue. As of now there is only one solution: get back to Mavericks!

 

Mieze

 

Sorry I think this is still the same problem I originally reported when I was still running Mavericks. :-) And other observations around here supports the idea that it may be in OSX's network stack, but it's not new as of Yosemite.

 

I suspect it's all still about IPv6, and whatever-it-is being mitigated by running VMWare. I think actually the E1000e.kext I'm running *is* your patched one to try to resolve that issue (version number wasn't changed so hard to tell!) but I recall that fix stopped working in Yosemite. (Reported here by me Oct 25)

 

Since my issue a day or so ago I've been forcing major traffic to go via IPv4 in nfs and ssh, and haven't had any more issues. OTOH *until* a day or so ago I hadn't had any such issues on the RTL since installing it, so another day without issues doesn't prove much. The problem basically is, until you wrangle with ssh config and auto_nfs files directly to force the issue one way or another, the system's choice between IPv4 and IPv6 when opening a connection is effectively random; and it may just have been choosing IPv4 more frequently for a while.

 

I am at least in a position to do some extra testing; I still have my Real Mac Mini (MM Server mid-2013 Macmini5,3), still with Mavericks on, sitting on a shelf waiting to be sold. I can try the same sort of transfers over IPv6 and see if it does indeed suffer the same problem. I'll try to fit in some testing of this soon.

Share this post


Link to post
Share on other sites

Just to put this to rest i did the following:

Installed a fresh version of Yosemite on a fresh disk, then only connected to the NAS and transfered one single large file.
This works! It finishes.

 

But... Then i start to copy several files at the same time, large ones - then the network shuts down.

I tried with IntelE1000 all versions since 2.4 up to 3.10 - all the same.
I tried with Realtek 8111 - all the same.
I tried with USB 3.0 Network - All the same.
I tried with WiFi Dongle - All the same.

And finally i tried to disable on-board network card, same {censored} still - It seems the whole network stack dies when the card is under heavy load with several threads.

PS: It's not IPv6, it's completely disabled on OS X and on the NAS.


Well, I think that Yosemite's network stack is broken and causes all those problems when it gets under load. That's why I'm staying with Mavericks until they manage to fix the issue. As of now there is only one solution: get back to Mavericks!

 

Mieze

 

After doing all the tests above and reading about everyone with a real Mac and Macbook having the same problems over at Apple forum, I believe you are completely right.

Share this post


Link to post
Share on other sites

Just to put this to rest i did the following:

 

Installed a fresh version of Yosemite on a fresh disk, then only connected to the NAS and transfered one single large file.

This works! It finishes.

 

But... Then i start to copy several files at the same time, large ones - then the network shuts down.

 

I tried with IntelE1000 all versions since 2.4 up to 3.10 - all the same.

I tried with Realtek 8111 - all the same.

I tried with USB 3.0 Network - All the same.

I tried with WiFi Dongle - All the same.

 

And finally i tried to disable on-board network card, same {censored} still - It seems the whole network stack dies when the card is under heavy load with several threads.

 

PS: It's not IPv6, it's completely disabled on OS X and on the NAS.

 

After doing all the tests above and reading about everyone with a real Mac and Macbook having the same problems over at Apple forum, I believe you are completely right.

 

concur it's not IPv6. I was about to report separately. It just happened to me on a transfer over an NFS link specified in mount options to be IPv4. It's the first time that's been definitively the case for me, but yes, it proves a point.

concur it's not IPv6. I was about to report separately. It just happened to me on a transfer over an NFS link specified in mount options to be IPv4. It's the first time that's been definitively the case for me, but yes, it proves a point.

 

not saying it isn't an apple bug but... my transfers are going to a Linux (Ubuntu) server. Most consumer NASs also run Linux, often in a more embedded form, but the network stack would be the same.

hmm.

 

Also,for the first time contradicting previous observations, that session where it crashed for me, vmware was running (with a virtual machine, network-configured for NAT). So the previously reported protective effect of running vmware didn't apply this time.

Share this post


Link to post
Share on other sites

 

not saying it isn't an apple bug but... my transfers are going to a Linux (Ubuntu) server. Most consumer NASs also run Linux, often in a more embedded form, but the network stack would be the same.

hmm.

 

Also,for the first time contradicting previous observations, that session where it crashed for me, vmware was running (with a virtual machine, network-configured for NAT). So the previously reported protective effect of running vmware didn't apply this time.

 

I'm running FreeNAS and have tried with AFP, SMB and NFS (v3 and v4) and the symptom is the same, the network stack just dies on heavy load. Doesn't even have to be that fast, at 30-40MB/s with many connections, it just take a little while longer until it dies. It's like a buffer fills up and then never get emptied, so it crashes...

 

I am at least in a position to do some extra testing; I still have my Real Mac Mini (MM Server mid-2013 Macmini5,3), still with Mavericks on, sitting on a shelf waiting to be sold. I can try the same sort of transfers over IPv6 and see if it does indeed suffer the same problem. I'll try to fit in some testing of this soon.

 

Did you get a chance to try this with a real Mac?

I have a Macbook Air, but it doesn't have a wired connection.

Share this post


Link to post
Share on other sites

I'm running FreeNAS and have tried with AFP, SMB and NFS (v3 and v4) and the symptom is the same, the network stack just dies on heavy load. Doesn't even have to be that fast, at 30-40MB/s with many connections, it just take a little while longer until it dies. It's like a buffer fills up and then never get emptied, so it crashes...

 

Did you get a chance to try this with a real Mac?

I have a Macbook Air, but it doesn't have a wired connection.

 

Yes, I've found in the past that it's fileshare-protocol independent; happened equally with SMB, NFS, SSH; also rsync over all of these. (not tried AFP). I find it quite random though, hence problems I've had proving the negative :-) For me, it even happens when I'm trying hard to make the transfer in question the *only* transfer going on (because I'm not trying to test this, just trying to get some files moved for real); but I can also go several days with it working just fine, then it'll go bad, and in fact stay bad over reboots and *even* powercycles. Currently I'm running VMWare.app again since the last spate and it hasn't happened again since doing so, but given I did have it happen one-time when I *was* running vmware (with a vm running) I'm no longer as sure as I was that it made a difference; could just have been coincidence.

 

I haven't got that real-mac test going I'm afraid; a getting-around-to-it failure, what with being away this weekend; the hard part is finding somewhere to plug it in so it can be conveniently used!

Share this post


Link to post
Share on other sites

I had a similar problem in the Mountain Lion days. My board has an Intel ethernet controller and I was using whatever version of hnak's driver was current at the time. In my quest to eliminate possible causes I went back from a slightly overclocked BCLK and I added an SSDT to describe my CPU overclock correctly. That stoped the crashes for me. Any chance you have overclocked your system?

 

Another idea: if your board has Thunderbolt, you could buy a Thunderbolt-Ethernet dongle from Apple to try to figure out whether the problem is with the OS or the driver. Then again, for the price you can probably buy a supported ethernet PCI card...

Share this post


Link to post
Share on other sites

Yes, I've found in the past that it's fileshare-protocol independent; happened equally with SMB, NFS, SSH; also rsync over all of these. (not tried AFP). I find it quite random though, hence problems I've had proving the negative :-) For me, it even happens when I'm trying hard to make the transfer in question the *only* transfer going on (because I'm not trying to test this, just trying to get some files moved for real); but I can also go several days with it working just fine, then it'll go bad, and in fact stay bad over reboots and *even* powercycles. Currently I'm running VMWare.app again since the last spate and it hasn't happened again since doing so, but given I did have it happen one-time when I *was* running vmware (with a vm running) I'm no longer as sure as I was that it made a difference; could just have been coincidence.

 

I haven't got that real-mac test going I'm afraid; a getting-around-to-it failure, what with being away this weekend; the hard part is finding somewhere to plug it in so it can be conveniently used!

 

I have the same symptoms here too. Tried Hnak IntelE1000 drivers from v. 2.5.4 till 3.1.0 under Yosemite 10.10.1 . All the same: copying from/to NAS (Syno) leads to a very low transfer rates (drops from 80/100 MB/s to 5/6 MB/s or even lower) after some heavy load (+10GB or so). Sometimes Ethernet stops completely and I have to unplug/plug again to reset the stack. Protocols' independent: both AFP and SMB affected. 

 

Ordered a Realtek 8111 PCIEx NIC to test. And a Intel i210 NIC too. The latest should be native.

 

Tried also MBP copies from/to NAS , both from Wi-fi and from Thunderbolt-Ethernet adapter ... none of these had drops in speed transfers or hangs. This one leads me to the point that Mieze might be wrong in considering Yosemite TCP/IP stack the culprit . Maybe both the stack and kext... don't know...

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.



×