Date: Mon, 17 Oct 2005 16:55:06 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: alc@freebsd.org, current@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../../../vm/vm_map.c:2997 Message-ID: <200510171655.08053.jhb@freebsd.org> In-Reply-To: <20051015070239.GA50577@xor.obsecurity.org> References: <20051015070239.GA50577@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 15 October 2005 03:02 am, Kris Kennaway wrote: > I have got this panic 3 times tonight on a 12-processor sparc64 e4500, > but only once did it get as far as displaying a stack trace before > hanging. WITNESS was enabled (without WITNESS_SKIPSPIN) but did not > report anything. > > panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ > ../../../vm/vm_map.c:2997 > > cpuid = 3 > KDB: enter: panic > KDB: stack backtrace: > paiic:_lrocjm atoicl > croc+ x 3 > foBk_sxatk)bac foak_: > _fink(tr ol e ) a f tr e 0x > at sched_bind+0x78 > boot() at boot+0x24 > panic() at panic+0x1bc > longjmp() at longjmp+0x44 > trap() at trap+0x220 > -- fast data access mmu miss tar=0xe9f72000 %o7=0xc02f8284 -- > cpu_ipi_selected() at cpu_ipi_selected+0x2c > ipi_selected() at ipi_selected+0x14 > stop_cpus() at stop_cpus+0x1c > kdb_trap() at kdb_trap+0x64 > trap() at trap+0x264 > -- breakpoint %o7=0xc0191f74 -- > kdb_enter() at kdb_enter+0x3c > panic() at panic+0x164 > _mtx_lock_sleep() at _mtx_lock_sleep+0x40 > _mtx_lock_flags() at _mtx_lock_flags+0xa4 > _vm_map_lock_read() at _vm_map_lock_read+0x1c > vm_map_lookup() at vm_map_lookup+0x1c > vm_fault() at vm_fault+0x68 > trap_pfault() at trap_pfault+0x1a8 > trap() at trap+0x28c > -- fast data access mmu miss tar=0xe9f9a000 %o7=0xc02cea68 -- > vm_map_entry_splay() at vm_map_entry_splay+0x10 Real panic is here, the recursive mutex acquire is just spurious. > vm_map_find() at vm_map_find+0x34 > kmem_alloc_nofault() at kmem_alloc_nofault+0x44 > pmap_pinit() at pmap_pinit+0x30 > vmspace_zinit() at vmspace_zinit+0x14 > slab_zalloc() at slab_zalloc+0x264 > uma_zone_slab() at uma_zone_slab+0x12c > uma_zalloc_bucket() at uma_zalloc_bucket+0x16c > uma_zalloc_arg() at uma_zalloc_arg+0x374 > vmspace_alloc() at vmspace_alloc+0x14 > vmspace_fork() at vmspace_fork+0x24 > vm_forkproc() at vm_forkproc+0xe4 > fork1() at fork1+0xd44 > fork() at fork+0x10 > syscall() at syscall+0x2dc > -- syscall (2, FreeBSD ELF64, fork) %o7=0x110020 -- > -userland() at 0x40635568 > user trace: trap %o7=0x110020 > pc 0x40635568, sp 0x7fdffffd721 > pc 0x106890, sp 0x7fdffffd7e1 > pc 0x105fe4, sp 0x7fdffffd9a1 > pc 0x107428, sp 0x7fdffffdae1 > pc 0x110b88, sp 0x7fdffffdbc1 > pc 0x102354, sp 0x7fdffffdce1 > pc 0x40227474, sp 0x7fdffffdda1 > done > panic: mi_switch: did not reenter debugger > cpuid = 3 > KDB: stack backtrace: > > [At this point it looped recursively panicking for 5 minutes or so before > hanging]. > > Kris -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510171655.08053.jhb>