From owner-freebsd-hackers Sat Aug 3 9:13:59 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 B7A4537B400 for ; Sat, 3 Aug 2002 09:13:57 -0700 (PDT) Received: from tesla.distributel.net (nat.MTL.distributel.NET [66.38.181.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 208E543E42 for ; Sat, 3 Aug 2002 09:13:57 -0700 (PDT) (envelope-from bmilekic@unixdaemons.com) Received: (from bmilekic@localhost) by tesla.distributel.net (8.11.6/8.11.6) id g73GEOH36017; Sat, 3 Aug 2002 12:14:24 -0400 (EDT) (envelope-from bmilekic@unixdaemons.com) Date: Sat, 3 Aug 2002 12:14:19 -0400 From: Bosko Milekic To: "Stephane E. Potvin" Cc: freebsd-hackers@FreeBSD.ORG, Jeffrey Roberson Subject: Re: ARM Port: Help with UMA subsystem needed Message-ID: <20020803121419.A35909@unixdaemons.com> References: <20020801200512.B45139@hades.videotron.ca.> <20020803110711.C45139@hades.videotron.ca.> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20020803110711.C45139@hades.videotron.ca.>; from sepotvin@videotron.ca on Sat, Aug 03, 2002 at 11:07:11AM -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 11:07:11AM -0400, Stephane E. Potvin wrote: > On Thu, Aug 01, 2002 at 08:05:12PM -0400, Stephane E. Potvin wrote: > > I've been busy trying to bring the port back in sync with current. > > Now, each time I start my NetWinder, I get the following panic which > > I don't seem able to track the source. I would greatly appreciate if > > anybody knowledgeable with the UMA subsystem could give me a hint on > > what could be causing this. > > > > 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? Regards, -- 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