Date: Fri, 31 Dec 1999 02:35:33 +0200 (IST) From: Roman Shterenzon <roman@xpert.com> To: Bosko Milekic <bmilekic@dsuper.net> Cc: "Mr. K." <bsd@inbox.org>, stable@FreeBSD.ORG Subject: Re: Panic: Out of mbuf clusters Message-ID: <Pine.BSF.4.21.9912310232360.85199-100000@rs.ksl.co.il> In-Reply-To: <Pine.OSF.4.05.9912301855340.29156-100000@oracle.dsuper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.9912310232360.85199-100000>