Date: Fri, 07 Jul 2000 18:28:12 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: Mike Silbersack <silby@silby.com> Cc: "Richard A. Steenbergen" <ras@e-gerbil.net>, freebsd-net@FreeBSD.ORG Subject: Re: stuck in LAST_ACK Message-ID: <Pine.BSF.4.21.0007071824500.5328-100000@jehovah.technokratis.com> In-Reply-To: <Pine.BSF.4.21.0007071510310.77395-100000@achilles.silby.com>
index | next in thread | previous in thread | raw e-mail
On Fri, 7 Jul 2000, Mike Silbersack wrote:
>
> On Fri, 7 Jul 2000, Richard A. Steenbergen wrote:
>
> > The full LAST_ACK list was in a previous email, 4.0-STABLE, didn't think
> > the newreno stuff was an issue there.
>
> It's not newreno related, it's a fix that is related to sockets getting
> stuck in LAST_ACK when the system is low/out of mbufs. (And the patch has
> been mfc'd to 3 and 4.)
>
> How old is your -STABLE? The patch was added on June 8th or so. Although
> with your huge number of mbufs, I doubt you ran out an caused the
> situation.
Hmm, maybe if the system tries to allocate an mbuf, has none on
mmbfree, calls m_mballoc(), which calls kmem_malloc(), which cannot
eventually allocate a physical page, where (how) == M_DONTWAIT ==
M_NOWAIT, which returns NULL, and the code cannot sleep as (how) ==
M_DONWAIT, so you get NULL back and get into the problematic case if
this is a prior-June 8th-fix -STABLE.
>
> OTOH, the high number of mbufs/mbuf clusters you have is almost
> worrysome; a netkill on that box could eat up a LOT of memory, which won't
> get freed.
Yes, another reason to look into the mbuf subsystem free pages patch.
>
> Mike "Silby" Silbersack
>
>
>
>
>
--
Bosko Milekic * Voice/Mobile: 514.865.7738 * Pager: 514.921.0237
bmilekic@technokratis.com * http://www.technokratis.com/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007071824500.5328-100000>