Date: Mon, 4 Nov 2002 17:19:00 +0200 (EET) From: Iasen Kostov <ikostov@otel.net> To: Lefteris Tsintjelis <lefty@ene.asda.gr> Cc: freebsd-net@FreeBSD.ORG Subject: Re: mbufs exhausted - kernel panic Message-ID: <20021104165903.F76062-100000@shadowhand.OTEL.net> In-Reply-To: <3DC68735.F2008CDA@ene.asda.gr>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021104165903.F76062-100000>