Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ ../../../vm/vm_map.c:2997

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 _at_
> ../../../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_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org