On Thu, Jun 10, 2010 at 7:16 AM, John Baldwin <[email protected]> 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[email protected]"
