From owner-freebsd-current@FreeBSD.ORG Tue Feb 22 19:09:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D01D516A4CE; Tue, 22 Feb 2005 19:09:05 +0000 (GMT) Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3498B43D73; Tue, 22 Feb 2005 19:09:05 +0000 (GMT) (envelope-from alc@cs.rice.edu) Received: from localhost (calypso.cs.rice.edu [128.42.1.127]) by cs.rice.edu (Postfix) with ESMTP id 97ACE4A9AC; Tue, 22 Feb 2005 13:09:04 -0600 (CST) Received: from cs.rice.edu ([128.42.1.30]) by localhost (calypso.cs.rice.edu [128.42.1.127]) (amavisd-new, port 10024) with LMTP id 06595-01-57; Tue, 22 Feb 2005 13:09:04 -0600 (CST) Received: by cs.rice.edu (Postfix, from userid 19572) id 1EF6F4A9A2; Tue, 22 Feb 2005 13:09:04 -0600 (CST) Date: Tue, 22 Feb 2005 13:09:04 -0600 From: Alan Cox To: Ruslan Ermilov Message-ID: <20050222190904.GC26262@cs.rice.edu> References: <20050222110318.GA41460@ip.net.ua> <20050222142710.GA42507@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050222142710.GA42507@ip.net.ua> User-Agent: Mutt/1.4.2i X-Virus-Scanned: by amavis-2.2.1 at cs.rice.edu cc: Alan Cox cc: Bosko Milekic cc: Peter Grehan cc: current@FreeBSD.org Subject: Re: mutex lock assertion panic in vm_page_free() on sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2005 19:09:06 -0000 On Tue, Feb 22, 2005 at 04:27:11PM +0200, Ruslan Ermilov wrote: > On Tue, Feb 22, 2005 at 01:03:18PM +0200, Ruslan Ermilov wrote: > > Hi, > > > > I'm repeatedly getting the following panic (three-four times a day) > > on sparc64 running a fresh -CURRENT, building world: > > > > db> show msgbuf > > panic: mutex vm object not owned at /usr/src/sys/vm/vm_page.c:608 > > cpuid = 0 > > KDB: enter: panic > > exclusive sleep mutex vm page queue mutex r = 0 (0xc04be700) locked @ /usr/src/sys/sparc64/sparc64/vm_machdep.c:483 > > exclusive sleep mutex UMA lock r = 0 (0xc04bdcc0) locked @ /usr/src/sys/vm/uma_core.c:1485 > > exclusive sleep mutex Giant r = 0 (0xc0422728) locked @ /usr/src/sys/vm/vm_pageout.c:666 > > db> where > > Tracing pid 7 tid 100016 td 0xfffff80067c0c720 > > panic() at panic+0x16c > > _mtx_assert() at _mtx_assert+0x6c > > vm_page_remove() at vm_page_remove+0x34 > > vm_page_free_toq() at vm_page_free_toq+0xb8 > > vm_page_free() at vm_page_free+0x10 > > uma_small_free() at uma_small_free+0x54 > > zone_drain() at zone_drain+0x2e8 > > zone_foreach() at zone_foreach+0x3c > > uma_reclaim() at uma_reclaim+0x10 > > vm_pageout_scan() at vm_pageout_scan+0x13c > > vm_pageout() at vm_pageout+0x3e8 > > fork_exit() at fork_exit+0x9c > > fork_trampoline() at fork_trampoline+0x8 > > > I have no idea if this is the correct fix or not, but the necessary > vm_object_t locking is certainly missing in uma_small_free() on all > architectures implementing it (alpha, amd64, ia64, powerpc, and > sparc64). It is not. Take a look at uma_small_alloc(). You'll see that pages are allocated with the option VM_ALLOC_NOOBJ, meaning that they are not members of any vm object. Consequently, the page's object field should remain NULL and vm_page_remove() should never be executed. I'm afraid that something is trashing your vm_page_array. Could you print the contents of the offending page structure? Alan