Date: Sat, 3 Aug 2002 16:00:12 -0400 From: Bosko Milekic <bmilekic@unixdaemons.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: "Stephane E. Potvin" <sepotvin@videotron.ca>, freebsd-hackers@FreeBSD.ORG Subject: Re: ARM Port: Help with UMA subsystem needed Message-ID: <20020803160011.A36586@unixdaemons.com> In-Reply-To: <20020803154945.B26021-100000@mail.chesapeake.net>; from jroberson@chesapeake.net on Sat, Aug 03, 2002 at 03:51:20PM -0400 References: <20020803121419.A35909@unixdaemons.com> <20020803154945.B26021-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Aug 03, 2002 at 03:51:20PM -0400, Jeff Roberson wrote:
> These locks can not be made recurisve safely. In this case you would just
> recurse forever and never satisfy the allocation. All pmap modules do
> something like the following:
>
> static void *
> pmap_allocf(uma_zone_t zone, int bytes, u_int8_t *flags, int wait)
> {
> *flags = UMA_SLAB_PRIV;
> return (void *)kmem_alloc(kernel_map, bytes);
> }
>
> pvzone = uma_zcreate("PV ENTRY", sizeof (struct pv_entry), NULL,
> NULL,
> NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_VM);
> uma_zone_set_allocf(pvzone, pmap_allocf);
> uma_prealloc(pvzone, initial_pvs);
Assuming ARM is following the same example, perhaps it needs to
pre-allocate more pvs. Although I somehow doubt it's doing the right
thing here because the panic seems to happen early on during boot,
according to the trace first provided.
> Is arm using a seperate allocf?
>
> Jeff
--
Bosko Milekic * bmilekic@unixdaemons.com * bmilekic@FreeBSD.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020803160011.A36586>