site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com These settings are discussed here: <http://developer.apple.com/technicalnotes/Darwin/idxKernel-date.html> Good luck! -Mike _______________________________________________ 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... On Aug 18, 2005, at 10:24 AM, Russell Seehafer (RIT Student) wrote: I am writing a socket filter NKE that selectively swallows packets, sends information about that packet to a user process on the control socket, and waits for a response from the user process before deciding whether or not to re-inject the packet. The swallowing / re-injection happens on a per-socket basis. When I recieve certain sflt_event_t's (sock_evt_disconnecting, sock_evt_disconnected, and sock_evt_closing) I call a routine that drops all packets still queued on that socket. I call this routine when I am attached and detached from a socket as well. The app runs great for a period of time (I am able to selectively swallow and re- inject about 4,000 packets) but eventually I recieve the grey shutdown screen. I realize this could be due to a memory management problem somewhere in the nke, but I suspect that I am attempting to re-inject a packet on a socket that is not longer valid. My question is which of the sflt_event_t's tell me that a socket is no longer valid and that I should drop all of my remaining packets for that socket? Also, does the nature of this app raise any red flags, or bring to mind any key principals that I might be overlooking? Thanks for your help! The "grey shutdown screen" is called a kernel panic. The UI you are seeing is how it's handled for non-developer users/consumers. If you are working in the kernel then you should set different Open Firmware options that are more appropriate for such development work. There are various options including spewing the panic info to the console. You can also elect to use a second machine to debug it over Ethernet (2 machine debugging). <http://developer.apple.com/documentation/Darwin/Conceptual/ KernelProgramming/build/chapter_18_section_5.html> Since it sounds like to can (with some effort) reproduce the panic at will doing this is the next logical step and will probably identify the problem more quickly than guessing! The best resource I've found for these things is "Understanding and Debugging Kernel Panics" found at ADC Home > Reference Library > Technical Notes > Darwin > Kernel This email sent to site_archiver@lists.apple.com