Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Dec 2008 12:53:59 -0800
From:      "Jason DiCioccio" <jd@ods.org>
To:        freebsd-net@freebsd.org
Subject:   Steady leak of mbufs + panic()
Message-ID:  <f372a76b0812141253t5c778d1dv20afbcca3fa60c99@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
Hey all,  I'm running into a strange situation where every ~1.5 days, I will
have a kernel panic:

  Architecture: i386
  Architecture Version: 2
  Version String: FreeBSD 7.0-RELEASE-p6 #1: Sun Dec  7 17:16:36 EST 2008
    geniusj@update.ods.org:/usr/obj/usr/src/sys/UPDATE
  Panic String: kmem_malloc(16384): kmem_map too small: 536858624 total
allocated

  When tracking down the source of the inflated kmem, I noticed that the
mbufs/bytes allocated to network figures in netstat -m were growing steadily
up until the crash.  Before the crash, bytes allocated to network will be up
near 400MB with mbufs reaching nearly 2 million.  mbuf clusters will be in
the low hundreds, however.

  This box is running a decent assortment of network protocols and
functionality.  It's a fairly active DNS server (more active than most), it
is running a couple of instances of openvpn (tap), it's using gif for an
ipv6 tunnel which is then tunneled over openvpn as well, it's also using BGP
over the tunnels with quagga..

  The only thing I can think of that changed before this all started
happening is that I had added AAAA records for the nameserver (in the
registry as well as locally).  The inet6 traffic is fairly light, however
(with a total of ~1.5MB both in and out in the past 15 hours versus 580MB in
and 985MB out for the whole box.).

  Before I go down the bug report route, I'd like to know if there are
accepted conditions where mbufs will grow like this and where I might start
looking..  If more information would be helpful, let me know what's needed.

  Any help would be appreciated.

Thanks!
Jason DiCioccio



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f372a76b0812141253t5c778d1dv20afbcca3fa60c99>