Hi Eric (again :), one thought is to use your (faster) desktop machine with a small external disk for this testing. Don't have your large (internal) disk mounted. Just have the minimal stuff needed to test. Loading and unloading isn't the problem. The problem is that the test case produces a panic. I have to reboot after that. I tried a lot of things to try and isolate the trigger. What I found is that if I set the kextcb->e_fcb value to anything other than null in my test kext's socreate() hook, the third party extension will call panic(). I'm thinking, what business is it of theirs what that value is... besides the issue of why a kernel extension would ever call panic(). Seems to me if their kext is confused it should just bow out gracefully in any case. That's rather tacky. Why on earth would a kext be walking the kextcb chain to see what other kexts have put in that field of their own kextcb? The other kext can't just be accidentally stumbling across yours, as it is given a kextcb of its very own. So it has to be starting back at the head of the list and walking down. What this is really saying is that the other kext will panic() if there's any kext other than itself (perhaps, before itself). Regards.....Peter _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.