Date: Tue, 22 Feb 2005 14:22:56 -0500 From: Jung-uk Kim <jkim@niksun.com> To: freebsd-current@freebsd.org Cc: Peter Grehan <grehan@freebsd.org> Subject: Re: mutex lock assertion panic in vm_page_free() on sparc64 Message-ID: <200502221422.56994.jkim@niksun.com> In-Reply-To: <20050222190904.GC26262@cs.rice.edu> References: <20050222110318.GA41460@ip.net.ua> <20050222142710.GA42507@ip.net.ua> <20050222190904.GC26262@cs.rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 22 February 2005 02:09 pm, Alan Cox wrote: > 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? FYI, anholt says 'backing vm/uma_core.c to r1.114 has fixed the issue': http://docs.freebsd.org/cgi/mid.cgi?1109089389.4267.7.camel Jung-uk Kim > Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200502221422.56994.jkim>