Date: Mon, 7 May 2001 17:09:53 -0400 From: Bosko Milekic <bmilekic@technokratis.com> To: Pekka Savola <pekkas@netcore.fi> Cc: Luigi Rizzo <luigi@info.iet.unipi.it>, freebsd-stable@FreeBSD.ORG Subject: Re: 4.3-S: No buffer space available [SOLVED: dummynet] Message-ID: <20010507170953.A86359@technokratis.com> In-Reply-To: <Pine.LNX.4.33.0105070933300.24100-100000@netcore.fi>; from pekkas@netcore.fi on Mon, May 07, 2001 at 09:41:40AM %2B0300 References: <200105070625.IAA93694@info.iet.unipi.it> <Pine.LNX.4.33.0105070933300.24100-100000@netcore.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 07, 2001 at 09:41:40AM +0300, Pekka Savola wrote: > > dummynet consumes 1 mbuf/cluster per queue entry, so if you only > > have one pipe as above that should not be a major problem. > > I can only think of some leak, e.g. caused by mishandling of > > ipfw reconfigurations, but have no specific example in mind -- > > in any case, if the problem is there, you should see the > > number of mbufs in use go up with time. > > This should be no problem, I think -- netstat -m does not show significant > increase in mbuf usage; both mbuf and mbuf cluster peaks are well below > the average (see the original message). > > Of course, there _could_ be a surge just before the crash for some odd > reason. If I re-enable dummynet, I'll put in a cron job to monitor this > along with 'ipfw -ta l' and 'ipfw pipe list'. Any other issues to look > for? Earlier this week (or last week) in a post mentionning this behavior I saw the `netstat -m' output and, as you mention, the problem is not due to an mbuf or mbuf cluster shortage. The output revealed a very significant amount of remaining space in the mb_map. However, you could be running out of physical pages, although this is very unlikely. Check memory usage with top(1) to be sure. If, as I am assuming, it is not the latter, then I can see one or both of two `predictable problems:' 1. Somewhere ENOBUFS is returned even though the shortage is not the result of an mbuf or cluster shortage, but of some other network resource. 2. Bad stuff is happening in concerned code leading to the returning of ENOBUFS justifiably, in the sense that returning ENOBUFS is the correct thing to do, but getting to the point where we have to return ENOBUFS is not. As for exactly which of the two it is, I have no idea. If you are able to get the system to panic or die, enable debugging and try to reproduce. > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010507170953.A86359>