Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Jun 2005 12:46:58 -0500
From:      Alan Cox <alc@cs.rice.edu>
To:        David O'Brien <obrien@FreeBSD.org>
Cc:        Alan Cox <alc@FreeBSD.org>, cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/vm uma_int.h
Message-ID:  <20050617174658.GK5251@cs.rice.edu>
In-Reply-To: <20050617063914.GA1097@dragon.NUXI.org>
References:  <200506161706.j5GH6YgW038252@repoman.freebsd.org> <20050617063914.GA1097@dragon.NUXI.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 16, 2005 at 11:39:14PM -0700, David O'Brien wrote:
> On Thu, Jun 16, 2005 at 05:06:34PM +0000, Alan Cox wrote:
> > alc         2005-06-16 17:06:34 UTC
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     sys/vm               uma_int.h 
> >   Log:
> >   Increase UMA_BOOT_PAGES to prevent a crash during initialization.  See
> >   http://docs.FreeBSD.org/cgi/mid.cgi?42AD8270.8060906 for a detailed
> >   description of the crash.
> 
> Today, I finally got a traceback of my insta-reboots after marius' atkbd
> commit (2005-06-10 20:56:38 UTC) and it was exactly this same traceback.
> Funny that such an innocuous commit started causing my 'i386' workstation
> to panic.  We were that much on the edge of having enough UMA_BOOT_PAGES?
> Is 48 enough?

I recall that 42 was the minimum to fix Eric's panic.  I chose 48 so
that we would have some space to spare.

> It looks like the code attempts to help the poor user out:
>     sys/vm/uma_core.c:911:  panic("UMA: Increase UMA_BOOT_PAGES");
> But why wasn't that being triggered in Eric Anderson's case and mine?

My untested understanding of this problem has two parts. (1) UMA has
completed its own internal boot sequence.  Hence, the Boolean "booted"
is set to TRUE and the above panic does not occur.  (2) However, the
VM system has not completed its overall initialization.  Specifically,
the call to vm_init2() has not been performed.  Hence, the correct
allocator for the kernel address space's map entry zone has not been
set and any attempt to allocate a kernel map entry that is not
satisfiable from boot pages results in a panic.

Alan



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050617174658.GK5251>