From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 5 15:31:19 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 D5F4616A41C for ; Sun, 5 Jun 2005 15:31:19 +0000 (GMT) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: from smtp801.mail.ukl.yahoo.com (smtp801.mail.ukl.yahoo.com [217.12.12.138]) by mx1.FreeBSD.org (Postfix) with SMTP id 40E1E43D49 for ; Sun, 5 Jun 2005 15:31:19 +0000 (GMT) (envelope-from Thomas.Sparrevohn@btinternet.com) Received: (qmail 96503 invoked from network); 5 Jun 2005 15:31:17 -0000 Received: from unknown (HELO w2fzz0vc01.aah-go-on.com) (thomas.sparrevohn@hg1.btinternet.com@81.129.54.230 with plain) by smtp801.mail.ukl.yahoo.com with SMTP; 5 Jun 2005 15:31:17 -0000 From: Thomas Sparrevohn To: freebsd-hackers@freebsd.org, Poul-Henning Kamp Date: Sun, 5 Jun 2005 16:31:03 +0100 User-Agent: KMail/1.8 References: <200506051231.57725.Thomas.Sparrevohn@btinternet.com> <200506051317.21527.Thomas.Sparrevohn@btinternet.com> In-Reply-To: <200506051317.21527.Thomas.Sparrevohn@btinternet.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506051631.04750.Thomas.Sparrevohn@btinternet.com> Cc: Subject: Re: Debugging UMA allocation X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Thomas.Sparrevohn@btinternet.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Jun 2005 15:31:19 -0000 On Sunday 05 June 2005 13:17, Thomas Sparrevohn wrote: Ok - After a hand held trace - here are what happens In the call to uma_zcreate for the "PROC" object the slab_zalloc ends up being called twice - it in turn calls vm_map_lock and establishes the first time a exclusive sleep mutex on the region 0xc1059144 through a call to vm_map_lock in the startup_alloc - however that lock are nover released so when the second call to slab_zalloc is executed it in turns again calls startup_alloc which in turn again calls page_alloc->kmem_malloc->vm_map_lock with the same region which by now holds an exclusive lock that the first call established and the kernel panics Could it be because the "booted" vairable holds the value 1 or it that a long shot? > On Sunday 05 June 2005 12:31, Thomas Sparrevohn wrote: > > Ups - two useless files included - please ignore the plugins.txt and the > dmesg - it should have been > > > Hi > > > > One of the changes introduced after the 27/05 causes a panic in the > > initial boot phases in the > > > > The panic occurs on my Dell Lattitude C640 when using both my own kernel > > and the GENERIC kernel. > > > > The panic is > > _mtx_lock_sleep: Recursed on non-recursive mutex in system map > > > > I have traced the trigger panic to the first call to uma_zcreate in > > procinit called from proc0_init - I have just cvs-supped again but the > > error is still there > > > > Unfortunately because it happend before anything is up and running I have > > no way of producing a kernel dump and as the problem does not seem to be > > widely reported I assume it is specific to this Dell Laptop type > > > > The dmesg included are provided as reference only for the last good > > compilation of the that I know off e.g. the kernel I know that boots - I > > have been trying for about 2-3 days which should narrow down the time > > > > Can anybody give any advise on how to progress?