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. -- John BaldwinReceived on Thu Jun 10 2010 - 10:41:42 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:04 UTC