Date: Tue, 22 Feb 2005 13:09:04 -0600 From: Alan Cox <alc@cs.rice.edu> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: mutex lock assertion panic in vm_page_free() on sparc64 Message-ID: <20050222190904.GC26262@cs.rice.edu> In-Reply-To: <20050222142710.GA42507@ip.net.ua> References: <20050222110318.GA41460@ip.net.ua> <20050222142710.GA42507@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050222190904.GC26262>