From owner-freebsd-ppc@FreeBSD.ORG  Mon Feb 21 21:18:19 2005
Return-Path: <owner-freebsd-ppc@FreeBSD.ORG>
Delivered-To: freebsd-ppc@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8C34B16A4CE; Mon, 21 Feb 2005 21:18:19 +0000 (GMT)
Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au
	[203.22.124.10])	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 9CCE143D58; Mon, 21 Feb 2005 21:18:18 +0000 (GMT)
	(envelope-from grehan@freebsd.org)
Received: from [203.144.19.232] (CPE-19-232.dsl.OntheNet.net [203.144.19.232])
	j1LLHlnP044320;	Tue, 22 Feb 2005 07:17:48 +1000 (EST)
	(envelope-from grehan@freebsd.org)
Message-ID: <421A5169.8050904@freebsd.org>
Date: Tue, 22 Feb 2005 07:23:53 +1000
From: Peter Grehan <grehan@freebsd.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cokane@cokane.org
References: <4219D4FE.8080501@freebsd.org>
	<346a802205022108344070cf79@mail.gmail.com>
In-Reply-To: <346a802205022108344070cf79@mail.gmail.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
cc: bmilekic@freebsd.org
cc: freebsd-ppc@freebsd.org
Subject: Re: panic: mutex vm object not owned ...
X-BeenThere: freebsd-ppc@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Porting FreeBSD to the PowerPC <freebsd-ppc.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
	<mailto:freebsd-ppc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ppc>
List-Post: <mailto:freebsd-ppc@freebsd.org>
List-Help: <mailto:freebsd-ppc-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ppc>,
	<mailto:freebsd-ppc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Feb 2005 21:18:19 -0000

Coleman Kane wrote:

 > panic: mutex vm object not owned at /usr/src/sys/vm/vm_page.c:608
 >0xd7cc1ac8: at panic+0x134
 >0xd7cc1b68: at _mtx_assert+0x74
 >0xd7cc1b88: at vm_page_remove+0x5c
 >0xd7cc1ba8: at vm_page_free_toq+0xcc
 >0xd7cc1bc8: at vm_page_free+0x28
 >0xd7cc1be8: at uma_small_free+0x60
 >0xd7cc1c18: at zone_drain+0x2e8
 >0xd7cc1c58: at zone_foreach+0x64
 >0xd7cc1c78: at uma_reclaim+0x20
 >0xd7cc1c98: at vm_pageout_scan+0x200
 >0xd7cc1d58: at vm_pageout+0x39c
 >0xd7cc1d98: at fork_exit+0x118
 >0xd7cc1dc8: at fork_trampoline+0xc
  ...
> Yeah, I've been seeing this as well (on my AMD64 machine) lately. Any
> idea where it is from?

  Yes - it's rev 1.114 of uma_core.c. The comment "as the page(s) 
undoubtedly came from kmem_map for those two." isn't true for the
UMD_MD_SMALL_ALLOC case.

  It was assumed pre-1.114 that non-UMA_SLAB_KMEM were allocated with 
NULL backing objects, which can be seen from amd64/amd64/uma_machdep.c:

void *
uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait)
{
    ...
         *flags = UMA_SLAB_PRIV;

    ...
                  m = vm_page_alloc(NULL, colour++, pflags | 
VM_ALLOC_NOOBJ);
    ...


  Try backing out the couple of lines from that rev and see how it goes.

later,

Peter.