Bug 21240 - mbufs allocated to data is huge number in netstat -m
Summary: mbufs allocated to data is huge number in netstat -m
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 4.1-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2000-09-13 01:40 UTC by col
Modified: 2002-01-17 16:41 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description col 2000-09-13 01:40:01 UTC
After cvsup'ing from 4.1-RELEASE to 4.1-STABLE, I'm getting some strange
output from netstat -m

me# 4294789544/432/16384 mbufs in use (current/peak/max):
        4294789540 mbufs allocated to data
        4 mbufs allocated to packet headers
297/314/4096 mbuf clusters in use (current/peak/max)
736 Kbytes allocated to network (5440% in use)
0 requests for memory denied
0 requests for memory delayed
0 calls to protocol drain routines

I have found problem report kern/19809. This looks identical to the situation
there. However, I have only config'd 4K of mbufs. Here's some sysctl stuff
if it helps.. 

me# sysctl kern | grep mb
kern.ipc.nmbclusters: 4096
kern.ipc.mbuf_wait: 32
kern.ipc.mbtypes: 178151 4294789573 4 0 0 0 0 0 0 0 0 0 0 0 0 0
kern.ipc.nmbufs: 16384

I've also set maxusers to 256.

Fix: 

not sure, yet.
How-To-Repeat: Not sure if a different machine would do the same, yet, but add NMBCLUSERS = 4096,
change maxusers to 256 in GENERIC, build, reboot. Try netstat -m.
Comment 1 dwmalone 2000-09-13 09:42:34 UTC
On Tue, Sep 12, 2000 at 05:37:27PM -0700, col@pobox.com wrote:

> After cvsup'ing from 4.1-RELEASE to 4.1-STABLE, I'm getting some strange
> output from netstat -m

Are you sure you remembered to recompile both the kernel and world?
There were some changes to the mbuf counting stuff which might cause
netstat -m to display nonsense if it was out of sync with your kernel.

	David.
Comment 2 dwmalone freebsd_committer freebsd_triage 2000-09-13 09:43:13 UTC
State Changed
From-To: open->feedback

Waiting to check kernel and world in sync.
Comment 3 col 2000-09-13 19:29:17 UTC
I'm fairly sure the kernel and world are in sync. But, to be sure, 
here are the steps I took when doing the builds...

cd /usr/src
cvsup -g -L2 4.x-stable-supfile
make buildworld
make installworld
make buildkernel KERNEL=KERN
make installkernel KERNEL=KERN
reboot

Tried it several times and still seeing the same output from netstat -m.
I'm just thinking that after the changes from kern/19809 a couple weeks
ago, we might be seeing some unexpected behavior.

Thanks,

--Chad


Wed, Sep 13, 2000 at 01:45:03AM -0700, dwmalone@FreeBSD.org wrote:
> Synopsis: mbufs allocated to data is huge number in netstat -m
> 
> State-Changed-From-To: open->feedback
> State-Changed-By: dwmalone
> State-Changed-When: Wed Sep 13 01:43:13 PDT 2000
> State-Changed-Why: 
> Waiting to check kernel and world in sync.
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=21240
> 
>
Comment 4 bmilekic@dsuper.net 2000-11-12 04:04:34 UTC
  Hi,

  This is in relation to PR 21240.

  Do you happen to be using ET hardware? (www.etinc.com)

  I'm real curious, I've heard of related problems with exact same symptoms
  in conjunction with this hardware. I'm not sure at this time as to
  whether the problem is related to their driver, and it would be wrong to
  draw any conclusions. But your answer to this question would be a good
  thing to know.

  Cheers,
  Bosko Milekic
  bmilekic@technokratis.com
Comment 5 Sheldon Hearn freebsd_committer freebsd_triage 2002-01-17 16:12:05 UTC
State Changed
From-To: feedback->closed

Automatic feedback timeout.  If additional feedback that warrants 
the re-opening of this PR is available but not included in the 
audit trail, please include the feedback in a reply to this message 
(preserving the Subject line) and ask that the PR be re-opened.