Re: panic: uma_zone_slab is looping

  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
> _at__at_ -1926,6 +1926,7 _at__at_
>  {
>         uma_slab_t slab;
>         uma_keg_t keg;
> +       int i;
>  
>         keg = zone->uz_keg;
>  
> _at__at_ -1943,7 +1944,8 _at__at_
>  
>         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_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"

-- 
Bosko Milekic
bmilekic_at_technokratis.com
bmilekic_at_FreeBSD.org