AppleIntelE1000e.kext for 10.8/10.7/10.6/10.5

[MacUser2525]

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.

[StrangeNoises]

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.

[Himlaklar]

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.

[StrangeNoises]

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.

[Himlaklar]

 

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.

[StrangeNoises]

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!

[Mull7965]

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

[hackaro]

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

[StrangeNoises]

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.

[StrangeNoises]

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.

[StrangeNoises]

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.

[StrangeNoises]

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.

[hackaro]

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!  

[StrangeNoises]

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.

[Riley Freeman]

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.

[StrangeNoises]

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" ;-)

[Mieze]

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.

 

[puzhaenko]

 

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

[hackaro]

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.

 

 

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. 

[Himlaklar]

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.com/our-products/ethernet-adapters/jue130.html

 

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

[StrangeNoises]

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.com/our-products/ethernet-adapters/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)

[Mieze]

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 

Edited December 26, 2014 by Mieze

[StrangeNoises]

Just a follow-up as it's now a week since I put in the USB3->ethernet adapter; it's been working flawlessly under heavy loads for most of the week, both ways, simultaneously etc. also including to/from a VMWare virtual machine on the hackintosh host using bridged networking, and with IPv6 re-enabled (which I don't think made a difference either way, in the end). I've not had a single problem (though sods law dictates it'll fail two minutes after posting this). I've also continued to be unable to reproduce the fault on a real Mac Mini, though I haven't used it as heavily. It does certainly seem to exonerate the higher levels of the Yosemite network stack and point the finger back at these two drivers.

 

... which seems to be implicit in Mieze's announcement of work on a newly-developed version of the Intel driver. Much welcomed. My only thought, given both the Intel and RealTek drivers were having what looked like the same problem, was that they were both based on Linux drivers, and maybe - I can only offer in a vague way that I'm sure has already been considered - there's something in that that's more platform-specific than it outwardly appeared. For instance, process/thread/scheduling behaviour is exactly the sort of thing that's going to be where Linux and OS X differ in the gnarly detail. (Certainly this machine had been running Linux for a number of months before I turned it into a Hackintosh, and so presumably using the original Linux version of the relevant driver, with no problems whatsoever.)

[Mieze]

Just a follow-up as it's now a week since I put in the USB3->ethernet adapter; it's been working flawlessly under heavy loads for most of the week, both ways, simultaneously etc. also including to/from a VMWare virtual machine on the hackintosh host using bridged networking, and with IPv6 re-enabled (which I don't think made a difference either way, in the end). I've not had a single problem (though sods law dictates it'll fail two minutes after posting this). I've also continued to be unable to reproduce the fault on a real Mac Mini, though I haven't used it as heavily. It does certainly seem to exonerate the higher levels of the Yosemite network stack and point the finger back at these two drivers.

 

... which seems to be implicit in Mieze's announcement of work on a newly-developed version of the Intel driver. Much welcomed. My only thought, given both the Intel and RealTek drivers were having what looked like the same problem, was that they were both based on Linux drivers, and maybe - I can only offer in a vague way that I'm sure has already been considered - there's something in that that's more platform-specific than it outwardly appeared. For instance, process/thread/scheduling behaviour is exactly the sort of thing that's going to be where Linux and OS X differ in the gnarly detail. (Certainly this machine had been running Linux for a number of months before I turned it into a Hackintosh, and so presumably using the original Linux version of the relevant driver, with no problems whatsoever.)

 

You are right with regard to the fact that Linux and OS X drivers widely differ. There is a lot of stuff in Linux drivers which makes no sense on OS X or even does harm to the OS.

 

But I have to contradict the fact that the loss of network connectivity is caused by the driver because I have evidence that it must be the network stack as all of my drivers have a built-in watchdog timer, a software timer completely independent of the NIC, which fires when the NIC still has packets to transmit and there hasn't been any progress for a few seconds. Several users have reported problems with loss of network connectivity and send me kernel log files but I haven't seen a single one in which the watchdog timer fired in such a situation. Obviously the network stack stops feeding the driver with packets in certain situations. Maybe it's running out of buffer memory or the output queue gets stuck, who knows?

 

Mieze

[opiateESP]

I've been fighting with this issue since moving to Yosemite. Sucked. I regularly backup my Final Cut and Logic projects to a hackintosh server... needless to say, it's been painful to do. I happened to have a couple Intel CT Gigabit adaptors (82574L) sitting around. I put one in the server and one in my HackPro then used linux to change the Device ID's (as mentioned on the last page).

 

Problem solved. So much better!!!! Thanks a ton for that tip folks. Speeds are up to 75 mb/sec (upload) according to activity monitor.