site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com This mailing list really isn't a support channel in the first place. -- Terry http://lists.apple.com/archives/darwin-kernel/2007/Jun/msg00111.html - Greg On Jul 22, 2008, at 11:10 PM, Greg wrote: continuing continuing done CPU halted Much appreciated, - Greg _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/greg%40kinostudios.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... If you had NMI'ed the machine and done two machine debugging, it would have been clear from the stack traces you posted that the unmount was blocked by the vnode being held on the device. Similarly, if you had provided a cut down example that reproduced the problem, we could have done the same debugging on our own machines, and seen that the the unmount was being blocked by the vnode being held open on the device. Short of that, there's a bazillion things that could have caused the issue, and without knowing what you were doing, it's rather unreasonable to expect someone to pull an answer like that out of thin air 17 hours after you posted last night, and about 8 hours after most of us got enough caffeine in us to be able to read your post. As to why vnode_lookup() is not well documented: we don't want you doing file I/O from your KEXT. On Jul 23, 2008, at 4:25 PM, Greg wrote: After much trial and error I fixed the problem. I know that I'm probably not going to win any fans here by complaining, but I feel that Apple could do a whole lot more to document the kernel. While searching for a potential solution I discovered an email on this mailing list, from myself, asking for information about the vnode_lookup function: The only reply I received was from Michael telling me to look through the kernel source for example uses, which I did, couldn't find any examples, replied as such, and received no further replies. My entire experience writing the kernel extension has been one of poking around in the dark. Since kernel programming is already such a difficult and dangerous task, why should it be made even *more* difficult by providing virtually zero documentation for the API? Should third-party developers really be expected to simply know everything there is to know about how Darwin works before attempting to write a KEXT? If that's the case at the very least that should be stated somewhere in one of the introductory texts Apple offers like "KEXTConcept" or "KernelProgramming". My problem was solved by a single vnode_put function call after the vnode_lookup. The only reason I was able to figure this out was because I somehow managed to find in the depths of the mailing list an unanswered email about what the difference between 'vnode_put' and 'vnode_rele' was, and so I figured perhaps I needed to "release" the vnode_t given to me by vnode_lookup, which was not at all obvious even after looking at the source for vnode_lookup. Sorry for the rant. Hopefully this email might prove useful for somebody else encountering the same problem. Release your vnodes! Hi, I'm encountering an odd problem, that seems to be occurring on both 10.4 and 10.5. I have a C-based kernel extension (_start/ _stop routines) that is loaded by a launchd daemon on startup and unloaded on shutdown (when the daemon gets a signal). The kernel reports (via printf messages) that it has been unloaded, in other words the _stop function was called, and it got to a point where all resources should have been freed and then it returns KERN_SUCCESS. However, the output on the screen stops at the following and sits there: Proper shutdown (when the KEXT is not installed) results in this output: I'd be very grateful for any ideas or theories as to why this is happening, what could be going wrong, as I'm not sure where to look, everything seems to be right.. This email sent to greg@kinostudios.com This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com