Date: Thu, 10 Jun 2010 12:23:24 -0500 From: Alan Cox <alan.l.cox@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current@freebsd.org, Nathaniel W Filardo <nwf@cs.jhu.edu> Subject: Re: [sparc64] [panic] mutex vm object not owned Message-ID: <AANLkTim71FSw51tyzFE6EVwnPCT_b4JnMAdLdF_IkSWT@mail.gmail.com> In-Reply-To: <201006100816.24077.jhb@freebsd.org> References: <20100609212747.GF21929@gradx.cs.jhu.edu> <201006100816.24077.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 10, 2010 at 7:16 AM, John Baldwin <jhb@freebsd.org> wrote: > On Wednesday 09 June 2010 5:27:47 pm Nathaniel W Filardo wrote: > > Attempting to boot on (2-way SMP; SUN Fire V240) sparc64 a 9.0-CURRENT > > kernel built on Jun 9 at 14:41, and fully csup'd before building (I don't > > have the SVN revision number, sorry) yields, surprisingly late in the > boot > > process, this panic: > > > > panic: mutex vm object not owned at /systank/src/sys/vm/vm_object.c:1692 > > cpuid = 0 > > KDB: stack backtrace: > > panic() at panic+0x1c8 > > _mtx_assert() at _mtx_assert+0xb0 > > vm_object_collapse() at vm_object_collapse+0x28 > > vm_object_deallocate() at vm_object_deallocate+0x538 > > _vm_map_unlock() at _vm_map_unlock+0x64 > > vm_map_remove() at vm_map_remove+0x64 > > vmspace_exit() at vmspace_exit+0x100 > > exit1() at exit1+0x788 > > sys_exit() at sys_exit+0x10 > > syscallenter() at syscallenter+0x268 > > syscall() at syscall+0x74 > > -- syscall (1, FreeBSD ELF64, sys_exit) %o7=0x11980c -- > > userland() at 0x406fe8c8 > > user trace: trap %o7=0x11980c > > pc 0x406fe8c8, sp 0x7fdffff7611 > > done > > Uptime: 4m7s > > > > The system was, at the time, attempting to bring up its jails. > > > > Anything else that would be helpful to know? > > Can you get a crashdump? If so, it would be good to pull up gdb and check > the > value sof 'object' and 'robject' in the vm_object_deallocate() frame. > > That would be useful. None of the locking changes of the last few weeks have altered the vm object locking, so this assertion failure and stack trace come as something of a surprise. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTim71FSw51tyzFE6EVwnPCT_b4JnMAdLdF_IkSWT>