From owner-freebsd-stable Thu Dec 30 16:31:57 1999 Delivered-To: freebsd-stable@freebsd.org Received: from rs.ksl.co.il (rs.ksl.co.il [199.203.44.20]) by hub.freebsd.org (Postfix) with ESMTP id CDD4D14EBD for ; Thu, 30 Dec 1999 16:31:50 -0800 (PST) (envelope-from roman@xpert.com) Received: from localhost (roman@localhost) by rs.ksl.co.il (8.9.3/8.9.3) with ESMTP id CAA85229; Fri, 31 Dec 1999 02:35:33 +0200 (IST) X-Authentication-Warning: rs.ksl.co.il: roman owned process doing -bs Date: Fri, 31 Dec 1999 02:35:33 +0200 (IST) From: Roman Shterenzon To: Bosko Milekic Cc: "Mr. K." , stable@FreeBSD.ORG Subject: Re: Panic: Out of mbuf clusters In-Reply-To: Message-ID: Organization: Xpert UNIX Systems Ltd. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Good day, That's very scary, that means that a individual or group of individuals having a decent intenet link could bring a FreeBSD-stable machine to it's knees. Please correct me if I'm wrong. Is there nmbcluster number which cannot be exploited using current (I don't mean freebsd-current :) technology? On Thu, 30 Dec 1999, Bosko Milekic wrote: > > On Thu, 30 Dec 1999, Mr. K. wrote: > > !>OK, so I raised NMBCLUSTERS to 4096, and installed a second freebsd-stable > !>box also with NMBCLUSTERS at 4096, and I managed to have them both panic > !>at the same time (unfortunately, only one of them gave me a crash dump). > !>But anyway, here is the stack trace, hopefully someone can tell me if this > !>is the same as the known problem, and whether 4.0 would fix it. > !> > !>euclid# cd /var/crash > !>euclid# ls > !>bounds kernel.0 minfree vmcore.0 > !>euclid# gdb -k kernel.0 vmcore.0 > !>GNU gdb 4.18 > !>Copyright 1998 Free Software Foundation, Inc. > !>GDB is free software, covered by the GNU General Public License, and you > !>are > !>welcome to change it and/or distribute copies of it under certain > !>conditions. > !>Type "show copying" to see the conditions. > !>There is absolutely no warranty for GDB. Type "show warranty" for > !>details. > !>This GDB was configured as "i386-unknown-freebsd"... > !>IdlePTD 2392064 > !>initial pcb at 1e64a4 > !>panicstr: Out of mbuf clusters > !>panic messages: > !>--- > !>panic: Ouxl0: no memory for rx list -- packet dropped! > !>t of mbuf clusters > !> > > [snip] > > !>--- > !>#0 0xc01253bb in boot () > !>(kgdb) where > !>#0 0xc01253bb in boot () > !>#1 0xc0125640 in at_shutdown () > !>#2 0xc013b5ca in m_retryhdr () > !>#3 0xc013d283 in sosend () > !>#4 0xc01333e8 in soo_write () > !>#5 0xc0130332 in dofilewrite () > !>#6 0xc013023b in write () > !>#7 0xc01ac6a7 in syscall () > !>#8 0xc019fdcc in Xint0x80_syscall () > !>#9 0x8048983 in ?? () > !>#10 0x8048679 in ?? () > !>(kgdb) > > > Well, now. We can see that the actual panic occurs during a send() > syscall (and not as a result of anything in the driver). Since sosend() > calls the allocation routines with M_WAIT, this confirms the origin of > the panic. > At the same time, you can observe that the `xl' driver is > properly dropping packets when it runs out of memory. The panic problem > is solved in -CURRENT. However, if you ever see such messages as "no > memory for [...]" and it's coming from the `xl' driver, that's a good > indication -- assuming that this occurs often -- that you should higher > NMBCLUSTERS. > > Bosko. > > -- > Bosko Milekic > Email: bmilekic@dsuper.net > WWW: http://pages.infinit.net/bmilekic/ > -- > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-stable" in the body of the message > --Roman Shterenzon, UNIX System Administrator and Consultant [ Xpert UNIX Systems Ltd., Herzlia, Israel. Tel: +972-9-9522361 ] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message