From owner-freebsd-current@FreeBSD.ORG Mon Dec 20 23:41:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9080216A4CE for ; Mon, 20 Dec 2004 23:41:07 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B99E43D31 for ; Mon, 20 Dec 2004 23:41:07 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])iBKNf4qn063103; Mon, 20 Dec 2004 18:41:04 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id iBKNf4Vn063101; Mon, 20 Dec 2004 18:41:04 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Mon, 20 Dec 2004 18:41:04 -0500 From: Bosko Milekic To: Peter Holm Message-ID: <20041220234103.GA59225@technokratis.com> References: <20041209144233.GA46928@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041209144233.GA46928@peter.osted.lan> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Dec 2004 23:41:07 -0000 I realize it's been a while. Anyway, what I *think* is going on here is that slab_zalloc() is actually returning NULL even when called with M_WAITOK. Further inspection in slab_zalloc() reveals that this could come from several places. One of them is kmem_malloc() itself, which I doubt will ever return NULL if called with M_WAITOK. If this assumption is indeed correct, then the NULL must be being returned by slab_zalloc() itself, or due to a failed uma_zalloc_internal() call. It is also possible that slab_zalloc() returns NULL if the init that gets called for the zone fails. However, judging from the stack trace you provided, the init in question is mb_init_pack() (kern_mbuf.c). This particular init DOES perform an allocation and CAN in theory fail, but I believe it should be called with M_WAITOK as well, and so it should also never fail in theory. Have you gotten any further with the analysis of this particular trace? If not, I would suggest adding some more printf()s and analysis into slab_zalloc() itself, to see if that is indeed what is causing the infinite looping in uma_zone_slab() and, if so, attempt to figure out what part of slab_zalloc() is returning the NULL. Happy Holidays, -Bosko On Thu, Dec 09, 2004 at 03:42:33PM +0100, Peter Holm wrote: > I modified: > > $ cvs diff -u uma_core.c > Index: uma_core.c > =================================================================== > RCS file: /home/ncvs/src/sys/vm/uma_core.c,v > retrieving revision 1.110 > diff -u -r1.110 uma_core.c > --- uma_core.c 6 Nov 2004 11:43:30 -0000 1.110 > +++ uma_core.c 9 Dec 2004 14:38:32 -0000 > @@ -1926,6 +1926,7 @@ > { > uma_slab_t slab; > uma_keg_t keg; > + int i; > > keg = zone->uz_keg; > > @@ -1943,7 +1944,8 @@ > > slab = NULL; > > - for (;;) { > + for (i = 0;;i++) { > + KASSERT(i < 10000, ("uma_zone_slab is looping")); > /* > * Find a slab with some space. Prefer slabs that are partially > * used over those that are totally full. This helps to reduce > > > and caught this one: > http://www.holm.cc/stress/log/cons94.html > -- > Peter Holm > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org