On Wed, Nov 21, 2001 at 06:43:18PM -0500, Bosko Milekic wrote: > > >From the netstat output, it looks more like an application-level problem > having to do with exhausting socket buffer space. Whatever the cause of > the problem, it certainly isn't a lack of mbufs and/or clusters.
Sorry, my bad. It's actually dhclient which is printing this message when sendto(2) returns ENOBUFS. I had already traced this into the kernel and manage to post without double checking my memories... Anyway, it appears that the application isn't to blame, and the card isn't hosed either (I can usually manage to at least get pings through). So it must be the syscall failing, right? OK I'll just go back to adding printf's to the kernel and see what happens. Bye, Andrea > > Try verifying what is generating the messages. It could be coming from > a syscall or, it may be that the application is printing them. If it is > the latter (you should find the string in the application code), then > it's fairly trivial to figure the rest out. If not, I'd check the > network card driver you're using next. > > On Wed, Nov 21, 2001 at 05:01:16PM +0100, Andrea Campi wrote: > > This is a long-standing problem which is getting more and more annoying (or > > so I feel, might be just an impression). I was wondering if anybody might > > be interested in helping me debug and fix it. > > I can repeat this at will using Tivoli Storage Manager for Linux to backup > > my -CURRENT laptop. Basically, after a few minutes I start getting these > > messages; at that point networking is basically hosed until I kill TSM. > > > > First of all, is this just an application misbehaving and it should be fixed > > only by tuning some sysctl, or is it an OS bug proper? Note that -STABLE > > doesn't exhibit this problem. > > > > netstat -m output is as follow: > > > > mbuf usage: > > GEN list: 0/0 (in use/in pool) > > CPU #0 list: 71/144 (in use/in pool) > > Total: 71/144 (in use/in pool) > > Maximum number allowed on each CPU list: 512 > > Maximum possible: 18432 > > Allocated mbuf types: > > 46 mbufs allocated to data > > 25 mbufs allocated to packet headers > > 0% of mbuf map consumed > > mbuf cluster usage: > > GEN list: 0/0 (in use/in pool) > > CPU #0 list: 20/66 (in use/in pool) > > Total: 20/66 (in use/in pool) > > Maximum number allowed on each CPU list: 128 > > Maximum possible: 9216 > > 0% of cluster map consumed > > 168 KBytes of wired memory reserved (34% in use) > > 0 requests for memory denied > > 0 requests for memory delayed > > 0 calls to protocol drain routines > > > > > > Relevant parts of vmstat -m: > > > > Memory statistics by type Type Kern > > Type InUse MemUse HighUse Limit Requests Limit Limit Size(s) > > mbufmgr 65 31K 32K 31594K 268785 0 0 16,32,64,128,8K,32K > > > > What else is needed to diagnose this? It's been baffling me for much too long... > > > > > > Bye, > > Andrea > > > > -- > > Tagline generated by 'gensig' mail-client-independent .signature generator. > > Get your copy at http://www.geeks.com/~robf/gensig/ > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-current" in the body of the message > > > > -- > Bosko Milekic > [EMAIL PROTECTED] > -- It's not a bug, it's tradition! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message