site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com This is short, due to lack of time: On Jul 12, 2005, at 11:35 , Allan Hoeltje wrote: Look for other possibilities as well: are you always freeing the mbufs you are using? Hope this helps. Regards, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- It's not whether you win or lose... It's whether *I* win or lose. -------- _______________________________________________ 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... I am not sure I know what you mean here. I mean: ENOBUFS usually means no space of some kind - either no buffers or no space to put buffers in, depending. Since this is not a common problem for existing code, it seems likely that it is due to something you are doing, presumably incorrectly. In my ipf_input_func (and duplicated in my ipf_output_func) I make a copy of the complete mbuf_t * data via mbuf_copydata into my own _MALLOC space. I then ctl_enqueuedata my copy and then _FREE the copy. I do not see any other mbuf_ or ctl_ methods that might come into play here. The kern_ctl_reg structure used to register a kernel control has a ctl_sendsize field that says 0 means the default size but does not say what that default is nor does it say what the size is: bytes, kBytes, ...? I want to enqueue a full IP packet so I need the ctl_sendsize to be at least 2048 bytes. You should be aware that the mbuf accounting rules take into account all the space in an mbuf, whether you use it or not (e.g., if you allocate an mbuf with cluster, put 1 byte in the cluster, and enqueue it, you are docked for the size of the mbuf (256 bytes) + size of cluster (2048 bytes). You may already know this but it's worth emphasizing. Are you sure that the queue is getting filled up? The description of ctl_enqueuedata in sys/kern_control.h says a return code of ENOBUFS means the "queue is full or there are no free mbufs". Since there isn't an mbuf associated with the ctl_enqueuedata method I can only assume that some queue somewhere is full. [snip] <whine> There is not enough documentation in this area. The "Network Kernel Extensions Programming Guide" and "Kernel Programming" docs warn about how careful one needs to be when programming in the kernel and then gives you just enough information to make you dangerous. Where does a mere mortal learn about writing proper KEXTs? </whine> This is a no-whining zone. When the going gets tough, the tough get the kernel source and look at it to figure out what *might* be going wrong. A quick (and incomplete) check of the source tells me that the routine in question will return ENOBUFS if the receive sockbuf of the socket associated with the kctlref does not have sufficient free space; or when it can't allocate an mbuf (which it will use to store the data you pass it). This is pretty straight-forward, and will help you understand the environment you are developing code for. There are no courses on kernel internals, generally, and precious little documentation. You need to dig into the source. Thanks for the netstat tip - I will do some more debugging and see if I can't narrow this thing down some more. This email sent to site_archiver@lists.apple.com