AppleIntelE1000e.kext for 10.8/10.7/10.6/10.5

[bikinifarm]

Thanks for the Version 2.4.14 but the problem is not fixed.

Same here with the 2.4.14....copy a 150gb File to my network an the copy process dies at 20-25gb.....

 

Have here another System with same hardware on 10.8.5. Here works the network card correct with 2.5.4d and 2.4.14.....

 

Problem Macos 10.9 ???

This happens with subsequent versions, but not with 2.4.14. Make sure you have installed this kext in IONetworkingFamily.kext under Contents/Plugins and you have rebuilt the cache. Since this file is buried deep inside a kext, the cache typically does not get rebuilt unless you do a:

 

sudo touch /System/Library/Extensions

 

If unsure, boot without cache. All of this behavior has been reported here on this very forum a number of times, and nothing new. Please read previous posts.

[ila225]

Complementing what bikinifarm just said.

 

Assuming your AppleIntelE1000.kext is at your Desktop, these commands will do the trick:

sudo rm -rf /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleIntelE1000e.kext
sudo cp -R ~/Desktop/AppleIntelE1000e.kext /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/
sudo touch /System/Library/Extensions
sudo kextcache -u / 

You MUST make sure that kextcache has ran automatically after triggering kextd with the touch. That is the purpose of "kextcache -u /". Major difference in that is that the system runs with -F to decrease system performance impact, however, that might take several minutes sometimes depending if OS X thinks it should give more resources or not to the rebuilt. Since you're most likely going to just reboot right away, triggering kextcache forcibly allows you to reboot as soon as that kextcache is done.

 

By the way, you will probably find warning messages and details about kexts, specially the ones we usually mess with like AppleHDA, FakeSMC and others. AppleIntelE1000e is no exception, and should also be listed there. If it is not, then you probably had an issue with the installation.

[nbwallace]

Hi All,

 

I've rea this entire thread. I just updated my install from 10.8.3 to 10.8.5 and the network interface is not reported in the system report I am between 10.8.1 and 10.8.3 I was using AppleIntelE1000e.kext version 1.9.4 I am now trying 2.4.14 with no success.

 

My motherboard is an Intel DP55wb.

 

Any help would be greatly appreciated.

 

It's fixed. I removed npci=0x0300 from the boot.plist file. What a pain.

[ila225]

Hi All,

 

I've rea this entire thread. I just updated my install from 10.8.3 to 10.8.5 and the network interface is not reported in the system report I am between 10.8.1 and 10.8.3 I was using AppleIntelE1000e.kext version 1.9.4 I am now trying 2.4.14 with no success.

 

My motherboard is an Intel DP55wb.

 

Any help would be greatly appreciated.

 

Lets first check if the module is installed properly, shall we?

 

Would you be able to run and post the results for:

ls -l /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/ | grep E1000
kextstat | grep -i e1000
sudo dmesg | grep -i e1000

The last command will ask you for your password and if your machine has not been rebooted in the same day it will not give me the output I'm looking for.

[nbwallace]

It looks like it was due to the pci addressing. The npci command in the boot.plist this is from tonymac:

 

Because the npci=0x2000 and npci=0x3000 has to do with initialization of the PCI configuration space and when to initialize the signal. It has changed with this update and future updates from what I'm gathering. 

[ila225]

  So after running these commands, I got this error, from the last one (not sure if it's relevant):

 

sudo rm -rf /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleIntelE1000e.kext

sudo cp -R ~/Desktop/AppleIntelE1000e.kext /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/

sudo touch /System/Library/Extensions

sudo kextcache -u /

kxld[net.osx86.kexts.GenericUSBXHCI]: The following symbols are unresolved for this kext:

kxld[net.osx86.kexts.GenericUSBXHCI]: IOUSBControllerV2::_RESERVEDIOUSBControllerV226()

kxld[net.osx86.kexts.GenericUSBXHCI]: IOUSBControllerV3::_RESERVEDIOUSBControllerV320()

kxld[net.osx86.kexts.GenericUSBXHCI]: IOUSBControllerV3::_RESERVEDIOUSBControllerV321()

Link failed (error code 5).

Prelink failed for net.osx86.kexts.GenericUSBXHCI; aborting prelink.

Failed to generate prelinked kernel.

Child process /usr/sbin/kextcache[429] exited with status 71.

Error 107 rebuilding /System/Library/Caches/com.apple.kext.caches/Startup/kernelcache.

 

 

And here's my results from somebody else's request:

 

ls -l /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/ | grep E1000

drwxr-xr-x@ 3 root  wheel  102 Nov  6 16:28 AppleIntelE1000e.kext

beastie:desktop mm2margaret$ kextstat | grep -i e1000

   37    0 0xffffff7f809ca000 0x19000    0x19000    com.insanelymac.driver.AppleIntelE1000e (2.4.14) <18 10 5 4 3 1>

beastie:desktop mm2margaret$ sudo dmesg | grep -i e1000

AppleIntelE1000e(Info): Interrupt Throttling Rate (ints/sec) set to dynamic conservative mode

AppleIntelE1000e(Info): changing MTU from 0 to 1500

AppleIntelE1000e(Info): AppleIntelE1000e:WOL = 2

AppleIntelE1000e: Ethernet address 94:de:80:67:c2:ac

AppleIntelE1000e(Info): e1000e NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

beastie:desktop mm2margaret$ 

 

Still not working....

 

 

So, here's what I did of late:

 

I put in a Realtek add-in gigabit card, added the driver kext into IONetworkingFamily, and that does work.  I have IP and am using it now to get to the web and post this message.

 

So, I kind of have what I want, which is a gigabit ethernet adapter in the box, but not really.  I just don't get why the built-in Intel 1000e is being so difficult in my Mac Hack.  Remember all, the built-in Intel adapter works in the same machine if this machine is booted into Windows 8.....

Well, several things wrong there.

 

First, those errors are VERY important. You're not generating a new cache, mainly because you have a module which is not proper for your installation. That module? GenericUSBXHCI.

 

Given it is not working, I would remove it for now, and then after we fix your ethernet you can install it again to work on your USB. You probably just have a bad or incompatible version.

 

Now, this line:

drwxr-xr-x@ 3 root  wheel  102 Nov  6 16:28 AppleIntelE1000e.kext

 

Tells me that you have ACLs on that kext, which should not be there. To fix it, run this:

sudo xattr -cr /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleIntelE1000e.kext

And then post the results of this command again just to check:

ls -l /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/ | grep E1000

There should be no "@" in the listing.

 

Then run the rebuild commands again to check if it works:

sudo touch /System/Library/Extensions
sudo kextcache -u /

Although your system is loading the kext, I wonder if after the boot we are not coming across any other issues due to those ACLs.

[ila225]

 

I did remove the GenericUSB kext

 

So, here's my results, after performing the commands you requested:

 

 

beastie:~ mm2margaret$ ls -l /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/ | grep E1000

drwxr-xr-x  3 root  wheel  102 Nov  6 16:28 AppleIntelE1000e.kext

 

And:

 

beastie:~ mm2margaret$ sudo touch /System/Library/Extensions

beastie:~ mm2margaret$ sudo kextcache -u /

 

(meaning no errors, I think, because it didn't kick out anything....)

 

And, sadly, still no luck.....still getting a 169.254 address, and even a valid manual ip address assigned, I cannot ping it's default gateway, while the realtek can (if it's plugged in via an ethernet jack).

 

 

 

That is ok, one thing at a time.

 

Although your card was loaded, I wouldn't be surprised of weird behavior by the OS given the problems with permissions or cache. Granted, you could be booting without caches already, but it doesn't hurt to be sure.

 

I'm assuming you can still find your card being loaded properly and everything.

 

Next step you could try is to reset your network interface settings, by moving the config file out of the system configuration folder and then restarting:

mv /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist ~/Desktop

Try that, see if it helps.

[ila225]

Now I'm running out of ideas... =/

[Konner]

I wanna go ahead and post here, I have constant connection drops when downloading and trying to listen to music or browse the web. I've tried different versions and still the same problem.

 

I'm using Mavericks, and it's really getting annoying having to reboot to get internet back. can someone please help me?

 

the device is 

Intel® 82583V Gigabit Ethernet Controller

[Mieze]

It's really fatal, which means that kernel failed in locking physical memory for output buffer. I have never seen that.

Hey hnak,

 

maybe I can help you to fix the problem because I have already seen and successfully fixed that problem in my Realtek driver. getPhysicalSegmentsWithCoalesce() tends to fail when the maximum number of segments is too low so that the system tries to coalesce the buffer by copying the fragments to a large, contiguous buffer. As mbufs for TSO operations may be highly fragmented choosing 32 for the maximum number of segments is not enough. After experimenting I found out that 40 eliminated the problem.

 

Mieze

[Gismo]

 

I wanna go ahead and post here, I have constant connection drops when downloading and trying to listen to music or browse the web. I've tried different versions and still the same problem.

 

I'm using Mavericks, and it's really getting annoying having to reboot to get internet back. can someone please help me?

 

the device is 

Intel® 82583V Gigabit Ethernet Controller

 

Hello hnak,

 

Can you fix this Problem in Mavericks 10.9. I have the same problem.

 

Regards

[bcc9]

I was running 2.4.14 fine under 10.8, but after upgrading to 10.9, the ethernet breaks after about 1 day of uptime. The system begins flooding the LAN with packets, causing collisions and saturating my gig-e hub. I just upgraded to 2.5.4d, hope that works better.

 

When the ethernet is malfunctioning, the display is also unresponsive so I can't really debug it further.

Ok, it took a lot longer for the bug to re-occur for me with the current release, but now it has, failing in the same way as the old version. Pretty nasty bug. And, it looks like this driver is no longer being actively maintained?

I have experience fixing ethernet drivers under *nix, but if this driver is going to continue being unmaintained, then the recommendations to switch to a pci-e gig-e card seem like good advice.

 

However I would disagree that a realtek nic or a usb ethernet solution are good choices - realtek doesn't have a great track record with their open source driver support (look at the bug history of the linux realtek driver if you want more info; basically you have a 3rd party user trying to guess the correct tweaks to support new hardware, with no public hardware specs).

 

So for users not willing to beta test this driver, I would recommend switching to an intel gig-e nic, one of the models currently supported natively by OSX. Looks like an intel 82574L based NIC, as mentioned by hannibal&karlson12 would be the cheapest solution. Such as the intel EXPI9301CTBLK which can be had for about $30.

 

... unless someone is working on stabilizing this driver for osx 10.9?

[Mieze]

Ok, it took a lot longer for the bug to re-occur for me with the current release, but now it has, failing in the same way as the old version. Pretty nasty bug. And, it looks like this driver is no longer being actively maintained?

I have experience fixing ethernet drivers under *nix, but if this driver is going to continue being unmaintained, then the recommendations to switch to a pci-e gig-e card seem like good advice.

However I would disagree that a realtek nic or a usb ethernet solution are good choices - realtek doesn't have a great track record with their open source driver support (look at the bug history of the linux realtek driver if you want more info; basically you have a 3rd party user trying to guess the correct tweaks to support new hardware, with no public hardware specs).

 

So for users not willing to beta test this driver, I would recommend switching to an intel gig-e nic, one of the models currently supported natively by OSX. Looks like an intel 82574L based NIC, as mentioned by hannibal&karlson12 would be the cheapest solution. Such as the intel EXPI9301CTBLK which can be had for about $30.

 

... unless someone is working on stabilizing this driver for osx 10.9?

I checked the source code during the last days and found a number of serious bugs with regard to transmission queue handling. It's not a wonder that the driver fails because it's unable to recover from a stalled queue.

 

Frankly, I'm not sure if it's better to fix the driver or start from scratch. Judging from my experience I think that it's saver and more efficient to reimplement all the code involved with packet transmission and reception than to warp some compatibility code around a linux driver because OS X's driver architecture differs a lot from linux. Only the hardware initialization is the same.

 

Although Realtek's policy not to provide any documentation without NDA is a major disadvantage, their gigabit NIC's aren't bad at all. They might lack a few of the advanced features of Intel or Broadcom NIC's but they work reliably  and fast, provided that the driver knows of their specific bugs. Yes, it's frustrating to have to reverse engineer a Windows driver in order to learn how to write good an OS X driver, but that doesn't matter if you are a user as it only affects the driver developer so that there is no reason not to buy a Realtek add-in card.

 

I'm currently making plans for my next project, a Haswell build and in case I decide to buy a board with an Intel NIC, I will need a reliable driver for it. Maybe I'll take care of the driver after the Christmas holidays?

 

Mieze

[ila225]

...

I'm currently making plans for my next project, a Haswell build and in case I decide to buy a board with an Intel NIC, I will need a reliable driver for it. Maybe I'll take care of the driver after the Christmas holidays?

 

Mieze

Oh we all hope you have the time for it. =)

[bcc9]

Historically, the realtek open source driver has been a bit unstable, with driver bugs including years worth of SMB protocol performance issues, poor jumbo frame support, stuck queues, etc. Meanwhile the intel 10/100/1000 driver was stable.

 

I think the stark difference in stability has been a direct byproduct of the different way these two companies handle driver support, NDA headaches from realtek being a part of that. While the realtek driver has seemed to finally reach stability under linux a few years ago, apparently the support methodology has remained unchanged.

 

First party intel driver source is available as soon as new hardware comes out, but for realtek, the driver source normally lags behind. I think it's rather telling about realtek's commitment that their last OSX driver release was in 9/2011.

 

On top of this, under OSX, the OS provides native, officially supported drivers for some intel nics and no native drivers for realtek ethernet.

 

This combined with the driver support issues, and the historical track record, are why IMO buying a realtek nic to get a stable ethernet driver is not the wisest choice, especially given how cheap some intel nics are.

 

That's not to say your realtek osx driver isn't a good one, I don't have reason to believe it isn't.

 

Should an end user need to be bothered with these details? Certainly not, but the details affect which choice is wisest for them nonetheless.

 

I agree that for the intel e1000e, osx support should be quite fixable (given that intel has a stable working open source solution available for reference).

 

I welcome your efforts. It's quite frustrating that the best solution at the moment appears to be to buy a NIC, given that the on-board hardware and intel open source are perfectly capable already.

[Mieze]

Historically, the realtek open source driver has been a bit unstable, with driver bugs including years worth of SMB protocol performance issues, poor jumbo frame support, stuck queues, etc. Meanwhile the intel 10/100/1000 driver was stable.

 

I think the stark difference in stability has been a direct byproduct of the different way these two companies handle driver support, NDA headaches from realtek being a part of that. While the realtek driver has seemed to finally reach stability under linux a few years ago, apparently the support methodology has remained unchanged.

 

First party intel driver source is available as soon as new hardware comes out, but for realtek, the driver source normally lags behind. I think it's rather telling about realtek's commitment that their last OSX driver release was in 9/2011.

 

 

 

Realtek makes inexpensive semiconductors for the Windows mass market. That's their business and that's why they have a business culture of the Microsoft style while Intel has shown a strong commitment to linux during the last decade. Nevertheless the progress of their linux driver during the last years is remarkable.

 

On top of this, under OSX, the OS provides native, officially supported drivers for some intel nics and no native drivers for realtek ethernet.

 

I don't remember Apple has ever used a Realtek NIC. Although they published the source of a driver for the RTL8139 as sample code years ago, I see no reason why they should write a driver for chips they don't use. Besides, the number of Apple supported Intel chips is limited and taking the price into account it boils down to 82574L based cards.

 

This combined with the driver support issues, and the historical track record, are why IMO buying a realtek nic to get a stable ethernet driver is not the wisest choice, especially given how cheap some intel nics are.

 

Well, Intel NICs have their bugs too, in particular the 82574L (used on cheap add-in cards) which is prone to receiver deadlocks.

 

That's not to say your realtek osx driver isn't a good one, I don't have reason to believe it isn't.

 

But I have: 8 month of stable operation on my OS X home server (24/7 uptime) without a single loss of network connectivity.

 

Should an end user need to be bothered with these details? Certainly not, but the details affect which choice is wisest for them nonetheless.

Yes of course, at least when you are using a hackintosh you should know what you are doing as it's your own responsibility to get a stable working machine. Otherwise I would recommend to go to the next Apple Store and pick a real Mac.

 

Mieze

[bcc9]

Glad you agree.

Now back to the bug reports

[frankiee]

kernel[0]: failed to getphysicalsegment in outputPacket.

 

I also got this twice.

 

Can also confirm problems with large network copies, in my case: Finder Error -36, no lockup though.

[Neso]

it's my first post here, but i had to because i had problem with my intel network adapter from ASUS rampage III gene. After using AppleIntelE1000e.kext for 2.14 up to 2.5, i had network connection, but on wake from sleep finder would froze, only the cursor was moving. Same would happen if i chose network adapter and made it inactive in system preferences.After searching for two month (because i needed sleep function), today i tried with Intel82566MM.kext seeing it had mu device id: 10ce in the .plist. Now sleep is working fine, inactive also works and i have network support. So if you have same dev_id or supported dev_id and have problems with sleep try this kext. I haven't tried yet but it says that this kext doesn't support some function of vmware so read before using.  

[questor42]

hnak, thanks for your work on the ethernet driver.

 

I have a Z77X-UD5H which has both an Intel GbE (AppleIntelE1000e-v2.5.4d) and Atheros GbE (ALXEthernet-v1.0.2).

 

I'm running 10.9.0.  WOL is working on the Atheros, but not working on the Intel.  The Atheros driver source is available here:  http://code.google.com/p/iats/downloads/list

 

Thanks again!

[tele]

here running osx 10.9.0 and i have gigabyte ga-z87x-oc with Intel GbE LAN chipset.

after starting up the DHCP does NOT connect to my Netgear DG834gt, and it appears as IP 169.254.x.x

 

if i disconnect and reconnect the ethernet cable from the router i get correct DHCP IP 192.168.0.x

internet seems to work but IT'S VERY SLOW, and after shut down i have same issue when start up the computer again.

 

my network specification taken from system profiler:

 

Type: Ethernet Controller

  Bus: PCI

  Vendor ID: 0x8086

  Device ID: 0x1503b

  Subsystem Vendor ID: 0x1458

  Subsystem ID: 0xe000

  Revision ID: 0x0004

  BSD name: en0

  Kext name: AppleIntelE1000e.kext

  Location: /System/Library/Extensions/IONetworkingFamily.kext/Contents/PlugIns/AppleIntelE1000e.kext

  Version: 2.4.14

[genzai]

 

  Version: 2.1.14

Why don't you start by using a newer version of the driver, especially since your on the newest intel chips. 2.4.14 is what most people find to be the most stable. You may also try 2.5.x and see if it works for you.

g\

[tele]

hey genzai

i reading you must reset kext cache and repair permission to replace a kext file, then restart and install the ethernet driver again… 

so i must delete the 2.4.14 kext from beast 6.0.1 and install the Network hnak's AppleIntelE1000e v2.5.4d from 6.0.0  ?

 

do you suggest to do this manually using app like kext wizard  ?

actually i'm a total noob, so could you explain how to "try" most recent ethernet driver without messing up all the system ?

if is possible, you can help me here by chat or PM ?

 

thanks a lot for you advice

[genzai]

 

thanks a lot for you advice

 

There are many ways to install and manage kexts. But first of all you are using 2.1.14 and you should try 2.4.14

Then if 2.4.14 is not stable for you, try the latest 2.5.4d.

 

You can use the beast tools if you want, there should be no extra steps needed.

g\

[tele]

sorrt my mistake...i typed it wrong… i'm actually using 2.4.14 and NOT 2.1.14  !!

i corrected my previous post… so i could try to use 2.5.x ?

what is latest driver ?