On Thu, Jun 10, 2010 at 7:16 AM, John Baldwin <jhb_at_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. AlanReceived on Thu Jun 10 2010 - 15:23:28 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:04 UTC