From owner-freebsd-hackers Sat Aug 3 15:33:27 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ABFAF37B400 for ; Sat, 3 Aug 2002 15:33:22 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE6B143E5E for ; Sat, 3 Aug 2002 15:33:21 -0700 (PDT) (envelope-from sepotvin@videotron.ca) Received: from hades.videotron.ca ([24.203.254.196]) by relais.videotron.ca (Videotron-Netscape Messaging Server v4.15 MTA-PRD4) with ESMTP id H0AHBW01.VJT for ; Sat, 3 Aug 2002 18:33:32 -0400 Received: from hades.videotron.ca. (localhost [127.0.0.1]) by hades.videotron.ca. (8.12.3/8.12.3) with ESMTP id g73NTvFX062006 for ; Sat, 3 Aug 2002 19:29:58 -0400 (EDT) (envelope-from spotvin@hades.videotron.ca) Received: (from spotvin@localhost) by hades.videotron.ca. (8.12.3/8.12.3/Submit) id g73NTv7R062005 for freebsd-hackers@FreeBSD.ORG; Sat, 3 Aug 2002 19:29:57 -0400 (EDT) Date: Sat, 3 Aug 2002 19:29:57 -0400 From: "Stephane E. Potvin" To: freebsd-hackers@FreeBSD.ORG Subject: Re: ARM Port: Help with UMA subsystem needed Message-ID: <20020803192957.D45139@hades.videotron.ca.> Mail-Followup-To: freebsd-hackers@FreeBSD.ORG References: <20020803121419.A35909@unixdaemons.com> <20020803154945.B26021-100000@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020803154945.B26021-100000@mail.chesapeake.net>; from jroberson@chesapeake.net on Sat, Aug 03, 2002 at 03:51:20PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, Aug 03, 2002 at 03:51:20PM -0400, Jeff Roberson wrote: > > On Sat, 3 Aug 2002, Bosko Milekic wrote: > > > > > On Sat, Aug 03, 2002 at 11:07:11AM -0400, Stephane E. Potvin wrote: > > > > > > I just found out that reverting this commit fixes the problem. Any > > > ideas about why other arches don't encouter the problem? > > > > > > jeff 2002/06/19 13:49:44 PDT > > > > > > Modified files: > > > sys/vm uma.h uma_core.c > > > Log: > > > - Remove bogus use of kmem_alloc that was inherited from the old zone > > > allocator. > > > > This looks like the problem, or at least that which uncovers the > > problem. The pmap code is calling the zone allocator as well and > > what happens is that you recurse on the kmem_map lockmgr lock because > > you allocate recursively from kmem_map. Previously, we could also > > allocate from kernel_map, if the kernel_map lockmgr lock wasn't held, > > so this way if we had a recursive call we would get around this > > problem. I think this whole thing is flaky in general (if this was > > the way to get around recursion, we should fix it). > > > > JHB and/or JeffR: why is the kmem_map lockmgr lock not recursive? > > > > 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); > > > Is arm using a seperate allocf? Ok, you'll have to pass me a pointy hat. When I brought back my code back in sync with current it seems that I overlooked that the pv entries needs to be allocated with a UMA_ZONE_VM flag. With this I'm now able to boot up to cpu_thread_setup (which I still need to implement). Thanks again and sorry for the false alarm Steph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message