From owner-freebsd-isp Wed May 8 18:43:48 1996 Return-Path: owner-isp Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id SAA21732 for isp-outgoing; Wed, 8 May 1996 18:43:48 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id SAA21679 Wed, 8 May 1996 18:43:08 -0700 (PDT) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA01217; Thu, 9 May 1996 11:18:23 +0930 From: Michael Smith Message-Id: <199605090148.LAA01217@genesis.atrad.adelaide.edu.au> Subject: Re: Continued MBUF problem with ET V.35 card To: randy@zyzzyva.com (Randy Terbush) Date: Thu, 9 May 1996 11:18:23 +0930 (CST) Cc: et-users@netrail.net, freebsd-isp@FreeBSD.ORG, stable@FreeBSD.ORG, current@FreeBSD.ORG In-Reply-To: <199605082224.RAA06107@sierra.zyzzyva.com> from "Randy Terbush" at May 8, 96 05:24:17 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-isp@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Randy Terbush stands accused of saying: > > As some of you may remember, I reported a problem with MBUF leakage > on a FreeBSD-stable system running an Emerging Technologies ET5025 > card. After Dennis' indication that the problem was FreeBSD-stable > and rather strong suggestion that I need to be running 2.1.0, I > have reinstalled this system running stock FreeBSD-2.1.0. The > problem still exists and can be directly related to activity over > the 56K connection. A much busier system of same kernel vintage > without the ET drivers hovers at around '75 mbufs in use' after > several days of uptime. The system will reach it's max of 4096K > after about 48 hours of uptime and eventually reboot. I'm at a loss > for how to track this down and would heartily welcome more > productive suggestions. Hit Dennis on the head and get him to admit that it's his drivers 8) > After: > 5:12PM up 3:24, 1 users, load averages: 0.00, 0.00, 0.00 > > => netstat -m > 792 mbufs in use: > 788 mbufs allocated to data > 2 mbufs allocated to packet headers > 1 mbufs allocated to protocol control blocks > 1 mbufs allocated to socket names and addresses Something, somewhere, is using mbufs and not returning them. I'd go through all the drivers that you're using, and add tallies to them to keep track of how many mbufs they've allocated. Do it something like this : int ifep_mbuftally = 0; #define MBUFTALLY ifep_mbuftally int ifep_mbcltally = 0; #define MBCLTALLY ifep_mbcltally Check all the other places in the kernel where mbufs are allocated and freed, and modify them to suit. Make a list of all the files, and all the tally variables. Then frob the M* macros in /sys/sys/mbuf.h something like this : #define MGET(m, how, type) { \ MALLOC((m), struct mbuf *, MSIZE, mbtypes[type], (how)); \ if (m) { \ (m)->m_type = (type); \ MBUFLOCK(mbstat.m_mtypes[type]++;) \ (m)->m_next = (struct mbuf *)NULL; \ (m)->m_nextpkt = (struct mbuf *)NULL; \ (m)->m_data = (m)->m_dat; \ (m)->m_flags = 0; \ } else \ (m) = m_retry((how), (type)); \ #ifdef MBUFTALLY if (m) MBUFTALLY++; #endif } ... obviously you'll have to do the reverse in the *FREE cases. Build a kernel with these sources. Use the -g argument to config to get debugging symbols in the output. Copy the built kernel to kernel.debug, and then say 'strip -d kernel', and 'make install'. Reboot with the new kernel. Once it's running, you can say : # gdb --kernel --se=kernel.debug --exec=/kernel --core=/dev/mem Once in kgdb, you can use the 'print' command to show the value of the various tally variables that you defined before. This should help you work out who is eating all your mbufs. -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] Collector of old Unix hardware. "Where are your PEZ?" The Tick [[