AppleIntelE1000e.kext for 10.8/10.7/10.6/10.5

[gilby101]

Makes a difference for many/most Ethernet interfaces. Look back in this thread a few months for setting TSO.

[rednous]

Trying to install Intel I218-V (0x15a18086) under Yosemite with AppleIntelE1000e.kext (v.3.0.1) and this is my experience so far:

 

1. AppleIntelE1000e.kext in /S/L/E/IONetworkingFamily.kext/Plugins/, repaired permissions and rebuilt cache

if NETIF_F_TSO=false then Yosemite boots, but there's no Ethernet adapter recognised...

 

2. AppleIntelE1000e.kext in /S/L/E/IONetworkingFamily.kext/Plugins/, repaired permissions and rebuilt cache

if NETIF_F_TSO=true then Yosemite hangs on this screen:

 

 

Suggestions and advices are appreciated and welcome

[hnak]

Trying to install Intel I218-V (0x15a18086) under Yosemite with AppleIntelE1000e.kext (v.3.0.1) and this is my experience so far:

 

1. AppleIntelE1000e.kext in /S/L/E/IONetworkingFamily.kext/Plugins/, repaired permissions and rebuilt cache

if NETIF_F_TSO=false then Yosemite boots, but there's no Ethernet adapter recognised...

 

2. AppleIntelE1000e.kext in /S/L/E/IONetworkingFamily.kext/Plugins/, repaired permissions and rebuilt cache

if NETIF_F_TSO=true then Yosemite hangs on this screen:

...

As NETIF_F_TSO flag is read after the driver is loaded, it has nothing to do with adapter recognition.

[Mieze]

Trying to install Intel I218-V (0x15a18086) under Yosemite with AppleIntelE1000e.kext (v.3.0.1) and this is my experience so far:

 

1. AppleIntelE1000e.kext in /S/L/E/IONetworkingFamily.kext/Plugins/, repaired permissions and rebuilt cache

if NETIF_F_TSO=false then Yosemite boots, but there's no Ethernet adapter recognised...

 

2. AppleIntelE1000e.kext in /S/L/E/IONetworkingFamily.kext/Plugins/, repaired permissions and rebuilt cache

if NETIF_F_TSO=true then Yosemite hangs on this screen:

 

Yes, hnak is right. As TSO is used only for large outbound TCP packets, it doesn't affect adapter recognition or basic functionality like DHCP or DNS at all. You might even be able to browse the web with a broken TSO implementation.

 

Mieze

[rednous]

As NETIF_F_TSO flag is read after the driver is loaded, it has nothing to do with adapter recognition.

 

 

Yes, hnak is right. As TSO is used only for large outbound TCP packets, it doesn't affect adapter recognition or basic functionality like DHCP or DNS at all. You might even be able to browse the web with a broken TSO implementation.

 

Mieze

 

Guys, thank you for the clarifications

 

 

My H97M Pro4 (i218v2) works after waking up, though it may depend on how deep your sleep setting is.

hnak, we're having the same motherboards -- form factor is different (mATX & ATX). Could you be so kind to tell / advice me how to get my I218-V recognised and utilised in Yosemite? Should I use the FixLAN=true in Clover? I guess Im doing something stupid & wrong...

 

Thanks again

[hnak]

 

hnak, we're having the same motherboards -- form factor is different (mATX & ATX). Could you be so kind to tell / advice me how to get my I218-V recognised and utilised in Yosemite? Should I use the FixLAN=true in Clover? I guess Im doing something stupid & wrong...

 

Thanks again

I have never had recognition problems with my motherboard. I have used various version of Clover ( 2953 now ) and set FixLAN_2000=true.

The only things I do after Clover installation are setting kext-dev-mode=1 and  copying boot/bootx64.efi as Suse/elilo.efi so that I can choose "SuSe" in setup, otherwise I cannot boot in UEFI mode.

You should try booting without the kext and manually loading by kextutil. Before booting, removal of Library/Preferences/SystemConfiguration/NetworkInterfaces.plist is recommended.

[robE]

I also have v-i218(2) on my asus h97m-plus and never had recognition problems @ yosemite or mavericks unless i forget to add kext-dev-mode=1

[StrangeNoises]

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... :-} )

[wastez]

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.

[the slug]

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.

[hnak]

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.

[the slug]

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.

[Mieze]

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

[the slug]

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. 

[Mieze]

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

[the slug]

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. 

[Himlaklar]

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.

[MacUser2525]

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.

[ganxiao]

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?

[Himlaklar]

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.

[StrangeNoises]

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

[Himlaklar]

...

 

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.

[Mieze]

@Himlaklar & StrangeNoises: Are you using Yosemite?

 

Mieze

[StrangeNoises]

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

[Mieze]

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