Date: Mon, 20 Dec 2004 18:41:04 -0500 From: Bosko Milekic <bmilekic@technokratis.com> To: Peter Holm <peter@holm.cc> Cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping Message-ID: <20041220234103.GA59225@technokratis.com> In-Reply-To: <20041209144233.GA46928@peter.osted.lan> References: <20041209144233.GA46928@peter.osted.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041220234103.GA59225>