site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com On Jul 11, 2005, at 16:53 , Allan Hoeltje wrote: You can use 'netstat' to get a handle on this: $ netstat -m 89 mbufs in use: 85 mbufs allocated to data 3 mbufs allocated to socket names and addresses 1 mbufs allocated to Appletalk data blocks 120/286 mbuf clusters in use 0/16 mbuf 4KB clusters in use 658 Kbytes allocated to network (39% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines Cheers, Justin -- Justin C. Walker, Curmudgeon-At-Large Institute for General Semantics -------- Some people have a mental horizon of radius zero, and call it their point of view. -- David Hilbert -------- _______________________________________________ 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 using ctl_enqueuedata() in my KEXT to send data to a client application. The client is reading the socket with recv( s, buff, BUFFER_LENGTH, MSG_WAITALL ). Everything seems to work fine but the ctl_enqueuedata() call in my KEXT eventually returns "ENOBUFS - The queue is full or there are no free mbufs." So, it appears that recv() does not remove data from the queue. What do I need to do so that ctl_enqueuedata() does not fill the queue? I do not see any other function calls in sys/kern_control.h that look appropriate. Look for other possibilities as well: are you always freeing the mbufs you are using? Are you sure that the queue is getting filled up? This lets you track what your mbuf usage looks like. If you see the 'in use' count rising, it's possible that you aren't freeing them properly. $ netstat -t Active Internet connections Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 192.168.2.7.49396 mail.mac.com.imaps ESTABLISHED .... If the receiver is not taking data off the queue, you will see his receive queue increasing (this shows you the byte count currently on the queue); likewise, if a send queue is climbing, or is non-zero and unchanging, there is likely something wrong there. Associating what's printed here with what's going on in the kernel is not straight-forward, but it's doable. Note that it is very unlikely that recv() is screwing things up; this routine is very heavily used, and I think we would have seen a problem before now, if there was one. That's not a guarantee, of course, but that's the way to bet. You are probably using the correct calls (if Josh is around, he may have a comment); now's when the tough get debugging. Consider syslogs and 2-machine debugging. It's good for your heart and arteries; and it tastes great too. :-} PS: there seems to be a bug in 'netstat'; using '-A' does not show the socket structure address for tcp4 sockets. rdar://4176992. Works on 10.3. This email sent to site_archiver@lists.apple.com