Jump to content

AppleIntelE1000e.kext for 10.8/10.7/10.6/10.5


  • Please log in to reply
738 replies to this topic

#721
StrangeNoises

StrangeNoises

    InsanelyMac Protégé

  • Members
  • Pip
  • 25 posts
  • Gender:Female

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.



#722
Himlaklar

Himlaklar

    InsanelyMac Protégé

  • Members
  • PipPip
  • 59 posts
  • Gender:Female
  • Location:Sweden

 

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.



#723
StrangeNoises

StrangeNoises

    InsanelyMac Protégé

  • Members
  • Pip
  • 25 posts
  • Gender:Female

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!



#724
Mull7965

Mull7965

    InsanelyMac Protégé

  • Members
  • Pip
  • 12 posts
  • Gender:Male
  • Location:Germany

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



#725
hackaro

hackaro

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
  • Gender:Male
  • Location:Italy

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



#726
StrangeNoises

StrangeNoises

    InsanelyMac Protégé

  • Members
  • Pip
  • 25 posts
  • Gender:Female

missed or didn't notice the notification when this came in...

 

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

 

Definitely not overlocking my system. Also no thunderbolt. I did try a Realtek 8111 card, with Mieze's driver, and had same symptoms; therefore reverted back to the internal intel card so I could get the slot back for a Radeon (this is a mini-itx board).

 

Have considered buying a USB3 ethernet adapter for a test of a similar colour, that avoids hackintosh drivers, though they come with, and apparently need, their own. They're cheap enough I may consider it again. If there's commonality between hnak's and mieze's drivers though, it may be that they were both ports from Linux drivers?

 

Might as well add some more obs in the time since my last post. :-)

 

It's *definitely* nothing to do with IPv6. I eventually disabled that all the way up at the router, so it's off for the whole LAN. It did not prevent this problem occurring. I should turn it on again, to see if it affects severity or likelihood though. I wanted to be sure of this because, if it *is* an OS X network stack bug, there had to be some reason why it wasn't affecting so many people, including high profile content creators, that there would be uproar about it actually hitting the non-tech news! If it was IPv6 only, that would help explain its rarity. But it doesn't seem to be.

 

Also eventually confirmed this specific problem *does* also still happen if VMWare's running, so whatever it does that helped with the separate IPv6 issue reported earlier in this thread, isn't relevant here. I think I expressed some hope that it was a few posts ago.

 

I have been able to get by and complete transfers by trying harder not to do too much other stuff while the transfer is taking place; generally now I actually quit everything else and walk away from the computer! There would still be bonjour chatter I'm sure, but it's presumably below the threshold, or I've just been lucky. But the fact that works supports another commenter's theory that it's related to multiple threads competing for the network.

 

(It's possible before when I said otherwise, it was enough that I might have had a finder window open on the destination, trying to create previews, or other ssh sessions open to the same server. ie: so other threads had traffic to the same server, even if not very much, and no other large file transfers going on.)

 

rsync over ssh to the remote server seems the most successful: The issue can and does still *happen*, but rsync promptly exits with an error, which can make recovery easier. If the transfer is done over a mounted filesystem (SMB & NFS tested), either through rsync or Finder or whatever, the process just hangs.

 

using --bwlimit on rsync to limit the throughput rate doesn't prevent it.

 

Observed continuous flashing of the activity indicator light on the ethernet interface and on the switch after the problem occurs. On one occasion at least it was flashing the activity indicators on *all* the connected ports on the switch; on others, just the ones connecting to this and the destination server. Thinking this may indicate any particular thread might deadlock when this problem occurs; in at least one case, probably some bonjour operation. This carried on perpetually after the connection had failed on the mac, and no further transfers were (apparently) taking place. Unplugging and plugging back in didn't resolve it, it just resumed on plugging back in.

 

I *can* reset by taking the interface down and up again from command line, ie:

sudo ifconfig en0 down
sudo ifconfig en0 up

After doing this, the connection works normally again. Wondering if this may be useful for debugging, as presumably what happens during down/up is understood by someone. :-) This is better than having to hard-reset the computer! And of course I should have tried it *much* earlier. It's also possible this only works in combination with using rsync over ssh, as that exits rather than hangs when the problem occurs. I was previously doing a hard reset rather than an orderly reboot because the orderly reboot was hanging.



#727
StrangeNoises

StrangeNoises

    InsanelyMac Protégé

  • Members
  • Pip
  • 25 posts
  • Gender:Female

Finally testing the real mac. (Mac Mini Server, late 2011 edition (Sandy Bridge) running OS X Mavericks).

 

I can't reproduce the effect transferring from this real mac, even with two transfers running to the server at once and other stuff going on (deliberately trying to keep it "busy". Also with transfers to the hackintosh.

 

I *also* can't reproduce the problem when transferring *to* this real mac from the yosemite hackintosh. ssh and smb transfers, plus a screensharing session going on through the whole lot and several shells open. Once again makes me wonder if it's to do with when the remote server is Linux (as most NASs are, though mine's a built server).

 

Still, it's hard to prove the negative, given the fundamentally random nature of the problem in the first place. But based on rough probability I would have expected at least one such failure in the period of testing.

 

But Mieze has speculated this is Yosemite specific, so the next task is to upgrade this last mac (of mine) to that and repeat.



#728
StrangeNoises

StrangeNoises

    InsanelyMac Protégé

  • Members
  • Pip
  • 25 posts
  • Gender:Female

Update: So far unable to reproduce the error on the real Mac Mini on Yosemite. I've been deliberately unkind to it too, far more so than when I've encountered it on the hackintosh. Multiple transfers to separate machines, other activity ongoing to those other machines too; solid as a rock.

 

A negative being hard to prove, I'll keep using it for such stuff for a while and report if that changes.



#729
StrangeNoises

StrangeNoises

    InsanelyMac Protégé

  • Members
  • Pip
  • 25 posts
  • Gender:Female

Interesting aside - I ordered a Plugable USB3 ethernet adapter, which should arrive sometime today. In the meantime I've received an email from Plugable pointing me at the driver to download - and it's described as USB3-E1000.

 

Just wondering if the driver itself cares if the "E1000" interface it finds is a USB one :-) I may give that a play later without the adapter plugged in, to see if it'll recognise and drive the onboard intel interface - and if so, whether it too shows this problem. Long shot but worth a try in an idle few minutes.



#730
hackaro

hackaro

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
  • Gender:Male
  • Location:Italy

Update: So far unable to reproduce the error on the real Mac Mini on Yosemite. I've been deliberately unkind to it too, far more so than when I've encountered it on the hackintosh. Multiple transfers to separate machines, other activity ongoing to those other machines too; solid as a rock.

 

A negative being hard to prove, I'll keep using it for such stuff for a while and report if that changes.

 

I tried also to reproduce the problem, not only on my MBP and I was unable to do it, but also on another hack laptop that has a broadcom wifi , which is OS X native, and even this machine did't drop transfers or hangs. Rock solid. Not the TCP/IP stack ... 


Interesting aside - I ordered a Plugable USB3 ethernet adapter, which should arrive sometime today. In the meantime I've received an email from Plugable pointing me at the driver to download - and it's described as USB3-E1000.

 

Just wondering if the driver itself cares if the "E1000" interface it finds is a USB one :-) I may give that a play later without the adapter plugged in, to see if it'll recognise and drive the onboard intel interface - and if so, whether it too shows this problem. Long shot but worth a try in an idle few minutes.

 

I ordered a CT Desktop Intel NIC (82754), which should be OS X native, but I've been unable to install it so far. This NIC has its own BIOS which start after the motherboard BIOS and requires CSM enabled in mobo's BIOS options. Which is incompatible with CLOVER in UEFI partition, as my machine has. 

 

Eventually at last I was able to boot but the Clover boot 1st page is not in Full HD as usual but in VGA and then, when the machine boots and gets to the login and the video sync is messed up and I cannot see anything readable on my monitor . Tried both DVI and HDMI, always the same. Tried with graphics option : 1920*1080 in Clover options, but nothing. 

 

Who has hints or knows how to install this NIC under CLOVER in UEFI partition, please PM me. Thanks! :) 



#731
StrangeNoises

StrangeNoises

    InsanelyMac Protégé

  • Members
  • Pip
  • 25 posts
  • Gender:Female

Well, the Plugable driver doesn't recognise the internal intel NIC; that was just a wild offchance, no loss. The USB interface itself does seem to work happily though. I'll start the kind of file transfers that caused my problem before in a bit, but in general usage it seems to work fine. Obviously does need their supplied driver to be installed.

 

I expect to get grief from the Mac App Store next time I actually want to buy/install something though, at which point I guess i just reinstall AppleIntelE1000e.kext so it sees an en0 with a MAC address it's happy with. I'll wait to do that when I need to though, so I know for myself when exactly that is.



#732
Riley Freeman

Riley Freeman

    InsanelyMac Legend

  • Members
  • PipPipPipPipPipPipPip
  • 935 posts
  • Gender:Male
  • Location:The Streets
I ordered a CT Desktop Intel NIC (82754), which should be OS X native, but I've been unable to install it so far. This NIC has its own BIOS which start after the motherboard BIOS and requires CSM enabled in mobo's BIOS options. Which is incompatible with CLOVER in UEFI partition, as my machine has.

 

To get the CT adapter recognised you have to edit the device ids to match the Apple IDs.

 

Whether that will allow it to work in a UEFI setup, I don't know.

 

There's a EFI driver here. If you extract the PREBOOT\APPS\EFI\EFIx64\EnnnnX3.EFI file and put it into Clover's drivers64UEFI folder it might work.



#733
StrangeNoises

StrangeNoises

    InsanelyMac Protégé

  • Members
  • Pip
  • 25 posts
  • Gender:Female

And well, weirdly TweetBot kept crashing on startup until I restored the AppleIntelE1000e.kext. Not sure what that's about; no such effect on other app store apps for instance.

 

But otherwise:

 

Unable (so far) to reproduce the network problem using the Plugable adapter. While copying many big files to the remote (linux) server over smb, simultaneously using ssh shells to same server, and playing a movie in vlc from that server at the same time.

 

Not only that, but transfer rates were solidly up around the 130MB/s mark, whereas it's very variable on the onboard interface (and on the realtek when i was using that) even when not failing completely.

 

This, plus being unable to reproduce the issue on a real mac is kinda looking like it's the drivers again. :-) But obviously i'll keep using this until it too breaks; which of course it may not, in which case it's solved for me. ;-)

 

Only remaining issue: I've now inadvertently taught my computer that "plugable" is an appropriate way to spell "pluggable" ;-)



#734
Mieze

Mieze

    Giant Cat

  • Coders
  • 574 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

I tried also to reproduce the problem, not only on my MBP and I was unable to do it, but also on another hack laptop that has a broadcom wifi , which is OS X native, and even this machine did't drop transfers or hangs. Rock solid. Not the TCP/IP stack ... 


 

I ordered a CT Desktop Intel NIC (82754), which should be OS X native, but I've been unable to install it so far. This NIC has its own BIOS which start after the motherboard BIOS and requires CSM enabled in mobo's BIOS options. Which is incompatible with CLOVER in UEFI partition, as my machine has. 

 

Eventually at last I was able to boot but the Clover boot 1st page is not in Full HD as usual but in VGA and then, when the machine boots and gets to the login and the video sync is messed up and I cannot see anything readable on my monitor . Tried both DVI and HDMI, always the same. Tried with graphics option : 1920*1080 in Clover options, but nothing. 

 

Who has hints or knows how to install this NIC under CLOVER in UEFI partition, please PM me. Thanks! :)

 

Usually it's save do disable CSM although the NIC has it's own BIOS as long as you don't need features like Network boot. Of course you will have to edit Apple's Intel82574L.kext in order to get the adapter recognized as Riley Freeman already mentioned.

 

:cat:



#735
puzhaenko

puzhaenko

    InsanelyMac Protégé

  • Members
  • Pip
  • 1 posts

 

I have 3 MBs with onboard Intel NIC.
 
The following MBs wake up from power-off (even with the previous driver) :
Gigabyte GA-Z97X-UD7 TH (i217)
Asrock H97M Pro4 (i218v2)
 
The following MB does not wake up:
Intel DH68DB (82579)
 
It seems whether WOL works or not depends on BIOS/UEFI/Hardware.
I have not investigated the differences of the settings among the MBs, but WOL is enabled.

 

Hi! Do you work sleep & wake on ASRock h97m pro4? I have not worked wake fom sleep. You send me the config.plist for clover? Help me please...

My hackintosh:

i5-4460

ASRock h97m pro4

Intel HD4600

OS X 10.10.1



#736
hackaro

hackaro

    InsanelyMac Protégé

  • Members
  • Pip
  • 6 posts
  • Gender:Male
  • Location:Italy

Usually it's save do disable CSM although the NIC has it's own BIOS as long as you don't need features like Network boot. Of course you will have to edit Apple's Intel82574L.kext in order to get the adapter recognized as Riley Freeman already mentioned.

 

:cat:

 

thanks Mieze :)

 

I've been successful in installing Intel CT Desktop NIC under Yosemite 10.10.1  and I can confirm you already that speed to/from NAS (Syno DS413; DSM 5.1 latest update) are back to normal. 

 

AFP: ~100MB/s reading; ~60MB/s writing

SMB: ~110MB/s reading; 80MB/s writing 

 

I will extensively test the card and then report back here. As soon as I receive the Realtek 8111 I'll do the same with your kext too. 

 

no hang or slow down so far. 



#737
Himlaklar

Himlaklar

    InsanelyMac Protégé

  • Members
  • PipPip
  • 59 posts
  • Gender:Female
  • Location:Sweden

People keep mentioning WiFi, but it ONLY happens on a wired connection.

 

I bought this USB 3.0 to Gigabit Ethernet adapter that has it's own proper OS X Driver - NOW IT WORKS!

 

http://www.j5create....ers/jue130.html

 

I can reach 80-100MB/s without issues even when copying many files!



#738
StrangeNoises

StrangeNoises

    InsanelyMac Protégé

  • Members
  • Pip
  • 25 posts
  • Gender:Female

People keep mentioning WiFi, but it ONLY happens on a wired connection.

 

I bought this USB 3.0 to Gigabit Ethernet adapter that has it's own proper OS X Driver - NOW IT WORKS!

 

http://www.j5create....ers/jue130.html

 

I can reach 80-100MB/s without issues even when copying many files!

 

I never mentioned wifi.  :)  Have no wifi on my hack, and no desire for it either.

 

That adapter looks like it's the same under the skin as the Plugable one I bought, which also identifies as an AX88179. And yes, so far for me, it's been working flawlessly. I'm slowly getting used to not having to be *gentle* with my network operations any more.

 

This looks like becoming a recommendation for anyone with network problems but a spare USB3 port.  :) (If just USB2, might as well use the Apple USB->Ethernet adapter)



#739
Mieze

Mieze

    Giant Cat

  • Coders
  • 574 posts
  • Gender:Female
  • Location:Germany
  • Interests:Cats

I just wanted to let you all know that I'm working on a new driver for the Intel gigabit ethernet NICs. Although I'm still in a very early stage of development, I already managed to get the driver to load and recognize the NIC. Link change detection is working too and packets are going out, but I still have trouble with reception. I will publish it here in the forum as soon as possible but don't expect me to be ready before January.

 

UPDATE: Packet reception has been fixed and transmitter deadlock detection is working. The driver recovers from tx deadlocks successfully and resumes operation. Now I'll have to fix tx checksum offload which is still broken.

 

Mieze  :cat:


Edited by Mieze, Today, 01:14 AM.






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy