Jump to content
hnak

AppleIntelE1000e.kext for 10.8/10.7/10.6/10.5

767 posts in this topic

Recommended Posts

Advertisement

I tried to debug my kernel with gdb. It seems that AppleIntelE1000e driver does not support this feature. A message said

 

kdp_pool: no debugger device

 

And the other computer cannot connect to this machine.

 

Just want to know if this is a driver feature? If so, is there any plan to implement it?

 

Thank you.

Share this post


Link to post
Share on other sites

The debugger interface is not implemented. Currently I have no plan.

When I did 2 machines debugging, I used Marvell Yukon supported by Apple.

 

Is it simple to implement the feature ?

Share this post


Link to post
Share on other sites

@hnak, could you tell me the model of the ethernet card you are using?

I have no idea about the debugger interface since  I didn't dig into it yet. However, this driver (https://github.com/pmj/virtio-net-osx) implemented that interface. Maybe we can read the source code of that to learn how to implement the kernel debugging.

 

UPDATED: I scanned the source code (virtio-net/virtio_net.cpp) and it looks not difficult :-)

Share this post


Link to post
Share on other sites

I happen to use virtio-net-osx with Virtualbox.

In case of real hardware, things are more complex as polled-mode must be set upon enable(IOKernelDebugger) call, and sendPcaket/receivePacket must avoid memory allocation.

 

. The driver must have a state-variable to prevent packet processing in interrupt handlers ( or disable interrupt )

. if enable(IOKernelDebugger) is called rather than enable(IONetworkInterface), the driver must pre-allocate send/receive buffers.

. The driver must use IOKernelDebugger::lock/unlock instead of spinlock/mutex in debugging mode.

 

So, the driver should override attachDebugger/enable/disable/sendPacket/receivePacket, add a state-variable and conditional code in place where lock/mutex is used and in interrupt handlers. It is not too difficult, but will take some time.

Share this post


Link to post
Share on other sites

Strange... in Mavericks AppleIntelE1000e.kext works in EFI/Clover/Kexts/10.10 but in Yosemite only works at S/L/E... does it happen with anybody else?

 

(FakeSMC.kext works in EFI/Clover/Kexts in Mavericks and Yosemite)

Share this post


Link to post
Share on other sites

Strange... in Mavericks AppleIntelE1000e.kext works in EFI/Clover/Kexts/10.10 but in Yosemite only works at S/L/E... does it happen with anybody else?

 

(FakeSMC.kext works in EFI/Clover/Kexts in Mavericks and Yosemite)

It will work if you rebuild cache.

Share this post


Link to post
Share on other sites

It will work if you rebuild cache.

 

To me, even rebuilding cache, only works in Clover/Kexts/10.10 if I install Clover without EFI partition... inside EFI partition it does not load... inside EFI I have an error, something like "can't load kext xxxxx" and at the end of the error message something about "dependencies"...

Share this post


Link to post
Share on other sites

To me, even rebuilding cache, only works in Clover/Kexts/10.10 if I install Clover without EFI partition... inside EFI partition it does not load... inside EFI I have an error, something like "can't load kext xxxxx" and at the end of the error message something about "dependencies"...

Boot without caches, then rebuild cache, then boot with cache.

 

The trick is you have to convince kextcache to include IONetworkingFamily.kext in the cache. Once it is in the cache, the dependencies for the AppleIntelE1000e.kext can be satisfied in a boot with caches. By getting both kexts to load while booting without caches, IONetworkingFamily.kext is placed in the cache (because it is in /S/L/E and it is loaded).

Share this post


Link to post
Share on other sites

Boot without caches, then rebuild cache, then boot with cache.

 

Thanks, RehabMan...

 

But while i do that process, can I put intelE1000e in EFI Partition? or do I need to place it inside S/L/E and so, after rebuilding cache, I delete it from there?

Or better, all I have to do is to load IONetworkingFamily.kext and rebuild cache?

Share this post


Link to post
Share on other sites

Thanks, RehabMan...

 

But while i do that process, can I put intelE1000e in EFI Partition? or do I need to place it inside S/L/E and so, after rebuilding cache, I delete it from there?

Or better, all I have to do is to load IONetworkingFamily.kext and rebuild cache?

 

I usually do the following, and the cache is built properly:

 

mv /System/Library/Extensions/IONetworkingFamily.kext ~/Desktop/

mv ~/Desktop/IONetworkingFamily.kext /System/Library/Extensions/

Share this post


Link to post
Share on other sites

I usually do the following, and the cache is built properly:

 

mv /System/Library/Extensions/IONetworkingFamily.kext ~/Desktop/

mv ~/Desktop/IONetworkingFamily.kext /System/Library/Extensions/

Ummm... same effect as:

sudo touch /System/Library/Extensions

Share this post


Link to post
Share on other sites

Thanks, RehabMan...

 

But while i do that process, can I put intelE1000e in EFI Partition? or do I need to place it inside S/L/E and so, after rebuilding cache, I delete it from there?

Or better, all I have to do is to load IONetworkingFamily.kext and rebuild cache?

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×