From owner-freebsd-net Mon Nov 4 7:19:13 2002 Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A85237B401 for ; Mon, 4 Nov 2002 07:19:11 -0800 (PST) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AB1C43E6E for ; Mon, 4 Nov 2002 07:19:10 -0800 (PST) (envelope-from ikostov@otel.net) Received: from judicator.otel.net ([212.36.9.113]) by mail.otel.net with esmtp (Exim 3.36 #1) id 188j0G-000OeZ-00; Mon, 04 Nov 2002 17:19:00 +0200 Date: Mon, 4 Nov 2002 17:19:00 +0200 (EET) From: Iasen Kostov To: Lefteris Tsintjelis Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbufs exhausted - kernel panic In-Reply-To: <3DC68735.F2008CDA@ene.asda.gr> Message-ID: <20021104165903.F76062-100000@shadowhand.OTEL.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I don't think that it will help - all 192.168.0.0/16 routes could possibly exhaust whole my RAM - besides kern.ipc.nmbufs is read-only :) and could be set only at boot time or in kernel config. But I think the problem here is in NFS client code in nfsm_reqh() (I've compiled DDB in the kernel) which is called from nfs_lookup and so on ... Mbufs exhaustion is just condition for this panic as I saw. On Mon, 4 Nov 2002, Lefteris Tsintjelis wrote: > You need to increase kern.ipc.nmbufs > > sysctl -w kern.ipc.nmbufs=... > > Iasen Kostov wrote: > > > > I've tested our LAN when I come to this: > > I ran nbtscan 192.168.0.0/16 after a 2-3 secs kernel started printing > > > > "All mbufs exhausted, see tuning(7)". > > if you cancel execution of nbtscan - everything is ok but: > > > > 10112/10112/10112 mbufs in use (current/peak/max): > > 9822 mbufs allocated to data > > 128/130/2528 mbuf clusters in use (current/peak/max) > > 2788 Kbytes allocated to network (36% of mb_map in use) > > 161 requests for memory denied > > 0 requests for memory delayed > > 8 calls to protocol drain routines > > > > and second after kernel paniced. > > After reboot tried this again and nothing has happend. > > Then I mounted a NFS directory exported from the other computer on the > > network and tried nebtscan 192.168.0.0/16 again ... and kernel paniced > > when I execute "ls" in the NFS mounted directory. > > > > Fatal trap 12: page fault while in kernel mode > > . > > . > > . > > current process = 272(ls) > > ... > > > > I can't use this machine for dumping kernel core becouse it's > > production server it should be up and running. But I'll try same at home. > > > > It seems that kernel mbuf are exhausted by the route cache or the > > arpresolver becouse I can see a lot of unresolved arp requests in the > > routing table. > > > > interface xl0 has 2 IPs > > inet 212.36.9.x netmask 0xfffffff8 broadcast 212.36.9.x > > inet 192.168.100.254 netmask 0xffff0000 broadcast 192.168.255.255 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message