Jump to content
751 posts in this topic

Recommended Posts

Yes, keep in in EFI/Clover/kexts... Booting ignore caches allows both it to load and IONetworkingFamily.kext.

 

Note: Personally, I don't keep my kexts on the EFI partition. You can't keep all of them there anyway (eg. AppleHDA injector), and if you're developing kexts, there is certain disadvantages to storing them there (error checking after installing a new build is better if they are in /S/L/E).

 

Thanks for the advice!!!!!

 
I'm not a developer or a coder ... maybe a graphic designer hehehe! But the fact is that I always let my kexts out of the S / L / E , trying to get a "cleaner", (more vanilla), installation ... but I have to confess that, in situations like this, it's really convenient to leave the kexts in S / L / E

Ummm... same effect as:

sudo touch /System/Library/Extensions

Not same at all. Since AppleIntelE1000e.kext is buried two levels down, swapping it and doing what you suggest does not rebuild the kext cache reflecting the swapping of the new version. Hence, this is why people install this kext and don't see its effects unless they happen to do something a bit more drastic to kick it into gear. However, when you move it out and back in, it rebuilds the kext wholesale including the bits two levels down. There are multiple and repeated occurrences of this happening in this very discussion if one cares to read.

What "levels" are you talking about?

That would be "two directory levels down", spelled out for your convenience. The file in question sits in:

 

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

 

As it should be painfully obvious that AppleIntelE1000e.kext sits two directory levels below IONetworkingFamily.kext and your touching /System/Library/Extensions does not do zip. Jeez.

That would be "two directory levels down", spelled out for your convenience. The file in question sits in:

 

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

 

As it should be painfully obvious that AppleIntelE1000e.kext sits two directory levels below IONetworkingFamily.kext and your touching /System/Library/Extensions does not do zip. Jeez.

It does not.

 

When I install AppleIntelE1000e.kext, I install it to /S/L/E, not as a PlugIn for IONetworkingFamily.kext. I like to keep kexts which Apple provides clean. There is no need to install networking kexts as PlugIns to IONetworkingFamily.kext.

 

Besides that, this entire discussion is concerning installing AppleIntelE1000e.kext to EFI/Clover/kexts, not anywhere in /S/L/E. You evidently missed the point of the discussion.

 

Perhaps you install it as a PlugIn. Personally, I consider it bad practice. Don't assume everyone else follows your idea of where to install it. And next time, read the content of the thread before becoming rude (and misinformed) with your responses.

 

Also, I stand by my assertion that moving a kext out of /S/L/E, then moving it back only serves to trigger a cache rebuild. It is therefore has the same effect as touch /S/L/E (the method documented by Apple to trigger a rebuild). Also, any time a cache rebuild is triggered all kexts are scanned and the kext cache is rebuild from scratch. So, it matters not at all where your kexts are installed -- you can always trigger a rebuild with 'touch /S*/L*/E*'. Your statement to the contrary is false.

  • Like 1

It does not.

 

When I install AppleIntelE1000e.kext, I install it to /S/L/E, not as a PlugIn for IONetworkingFamily.kext. I like to keep kexts which Apple provides clean. There is no need to install networking kexts as PlugIns to IONetworkingFamily.kext.

 

Besides that, this entire discussion is concerning installing AppleIntelE1000e.kext to EFI/Clover/kexts, not anywhere in /S/L/E. You evidently missed the point of the discussion.

 

Perhaps you install it as a PlugIn. Personally, I consider it bad practice. Don't assume everyone else follows your idea of where to install it. And next time, read the content of the thread before becoming rude (and misinformed) with your responses.

 

Also, I stand by my assertion that moving a kext out of /S/L/E, then moving it back only serves to trigger a cache rebuild. It is therefore has the same effect as touch /S/L/E (the method documented by Apple to trigger a rebuild). Also, any time a cache rebuild is triggered all kexts are scanned and the kext cache is rebuild from scratch. So, it matters not at all where your kexts are installed -- you can always trigger a rebuild with 'touch /S*/L*/E*'. Your statement to the contrary is false.

 

If you care to test, you can easily prove that swapping the buried kext does not trigger a proper rebuild of the cache, because Apple does not expect you to do that. As to the location of the kext, I put it where Apple puts it, also as recommended at the beginning of this discussion. Enough said.

If you care to test, you can easily prove that swapping the buried kext does not trigger a proper rebuild of the cache,

Of course it doesn't, and I never claimed it did. You have to trigger a cache rebuild the way documented by Apple ('touch /System/Library/Extensions')

 

As to the location of the kext, I put it where Apple puts it, also as recommended at the beginning of this discussion. Enough said.

Apple does not put AppleIntelE1000e.kext anywhere. I prefer not to bury hackintosh kexts in native kext PlugIn directories. You can have a difference of opinion. We will agree to disagree.

 

The discussion that I replied to was regarding how to make Ethernet kexts work when installed to EFI/Clover/kexts.

I would suggest to open up a new thread in order to discuss the best way to install a kext as this might be of interest to all users, not only those using AppleIntelE1000e.kext, and it would help to stick on the subject.

 

:cat:

I would suggest to open up a new thread in order to discuss the best way to install a kext as this might be of interest to all users, not only those using AppleIntelE1000e.kext, and it would help to stick on the subject.

 

:cat:

In my mind, the discussion is over. No need to open a thread. If the mods want to move the posts, so be it.

Can somebody have a look on the AppleIntelE1000e.kext.

Because since 10.9.5 and 10.10 sometimes the network gets broken after some time fast afp transfer.

The OS Versions before had no problem with it.

FWIW I don't use AFP on my network (any more) so if it was the change that fixed my issue that's causing this, I won't have encountered it.

 

(That said, I'm not sure that change is in the general release yet, is it? I'm still running the quickly-fixed version mieze made for me :) )

Can somebody have a look on the AppleIntelE1000e.kext.

Because since 10.9.5 and 10.10 sometimes the network gets broken after some time fast afp transfer.

The OS Versions before had no problem with it.

 

Please provide us with a log file showing the problem so that we have a starting point to track down the issue.

:cat:

In Wireshark this is the only thing what i get (but really often, the hole log is full with it):  Reasmmebly Error, protocol TCP: New fragment overlaps old data (retransmission?)

 

But also had to say that i didn´t get the error until now. (whats totaly typical)

In Wireshark this is the only thing what i get:  Reasmmebly Error, protocol TCP: New fragment overlaps old data (retransmission?)

 

But also had to say that i didn´t get the error until now. (whats totaly typical)

 

Looks more like a bug in Yosemite's network stack than in the driver? Anyway, it doesn't shed a good light on Apple's new OS.

 

:cat:

Hey, I'm currently working on a Nuc with I218V Lan card. My Problem occurs only after wake from sleep. WOL or USB Wake works fine, but with every wake the ethernet connection is lost until a reboot. I tried the 3.1.0 as well as the 2.5.4 neither of them is solving the problem. With my other build on a i217 i had none of these problems.

 

Someone has an idea of the cause?

Hey, I'm currently working on a Nuc with I218V Lan card. My Problem occurs only after wake from sleep. WOL or USB Wake works fine, but with every wake the ethernet connection is lost until a reboot. I tried the 3.1.0 as well as the 2.5.4 neither of them is solving the problem. With my other build on a i217 i had none of these problems.

 

Someone has an idea of the cause?

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

I now tried to disable NETIF_F_TSO.

Now the e1000_tx_map: failed to getphysicalsegment errors are gone.

Also the transferspeed over afp (writing on server) increases from 30 - 60 MB/s to 60 - 100 MB/s which is very good.

 

The strange thing is that iperf (tx) shows just between 450 - 550 Mbit/s instead of 850 - 900 Mbit/s.

iperf (rx) is the same value. (about 940 Mbit/s)

 

Can somebody help me with it?

 

@ Mieze 

Do you know if TSO4 is working as it should on the last version of this driver?

 

 

If i enable TSO and try to transfer over smb it is limited to 2 - 5 MB/s tx, which is incredible slow.

 

Wireshare shows a lot of retransmissions and out of order errors.

 

Edit:

Nobody is able to help here?

Edited by wastez
  • 2 weeks later...

My question might sound stupid, but does the AppleIntelE1000e.kext v.3.0.1 in the very first post will run and recognise i218v (0x15a18086) in 10.10 (Yosemite)?

Yosemite:

VER 3.1.0 stopped work after huge transfere data from network (doing fist time machine backup)

After transfere 200 of 600GB the driver stopped work. Only restart fixed.

Back to 2.4.14 - by far the most stable driver for my intel network until now, could transfer the remaining 400 gb to time capsule without any driver crash

  • Like 1

Yosemite:

VER 3.1.0 stopped work after huge transfere data from network (doing fist time machine backup)

After transfere 200 of 600GB the driver stopped work. Only restart fixed.

Back to 2.4.14 - by far the most stable driver for my intel network until now, could transfer the remaining 400 gb to time capsule without any driver crash

Have you set TSO to off ?

×
×
  • Create New...