panic: mb_dtor_pack: ref_cnt != 1

[Gleb Smirnoff]

On Fri, Nov 04, 2005 at 06:45:48PM +0100, Andre Oppermann wrote:
A> >This isssue is seen on 3 different PCs running recent -current, clients 
A> >for a FreeBSD-6 NFS server (same problem when the NFS server is NetBSD). 
A> >All 3 clients have a small RAM, which may be a cause for faster apparition 
A> >of the issue.
A> 
A> Hmmm...  There are way too many in the packet cache (zone). Normally they
A> should get free'd back into the mbuf and cluster zones if there are too 
A> many.
A> I have to track down why UMA isn't doing that.

I can easily reproduce the following situation:

glebius at morannon:~:|>vmstat -z | grep mbuf
mbuf_packet:     256,        0, 18446744073709526976,  24896,    68208
mbuf:            256,        0,   25026,     68,   470970
mbuf_cluster:   2048,    25280,   25280,      0,    25280
mbuf_jumbo_9k:  9216,        0,       0,      0,        0
mbuf_jumbo_16k: 16384,        0,       0,      0,        0
mbuf_ext_refcnt:    4,        0,       0,      0,        0

glebius at morannon:~:|>netstat -m
386/24964/25350 mbufs in use (current/cache/total)
384/24896/25280/25280 mbuf clusters in use (current/cache/total/max)
0/5/6576 sfbufs in use (current/peak/max)
864K/56033K/56897K bytes allocated to network (current/cache/total)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

In this state any cluster allocations fail.

All I need to do is to download several Mb via bge(4) NIC. Backing out
your changes fixes the problem.

-- 
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE