Re: panic: _mtx_lock_sleep: recursed on non-recursive mutex pmap _at_ ../../../i386/i386/pmap.c:1499

On Sunday 26 March 2006 20:45, Kris Kennaway wrote:
> panic: _mtx_lock_sleep: recursed on non-recursive mutex pmap _at_ ../../../i386/i386/pmap.c:1499
> 
> I ran a thousand or so processes on 7.0 and the system panicked with:
> 
> Approaching the limit on PV entries, increase the vm.pmap.shpgperproc tunable.
> panic: _mtx_lock_sleep: recursed on non-recursive mutex pmap _at_ ../../../i386/i386/pmap.c:1499
> 
> Tracing pid 31187 tid 102219 td 0xc9efa870
> kdb_enter(c06c2710) at kdb_enter+0x2b
> panic(c06c19b5,c06de9f3,c06e20f4,5db,c9faf2b8) at panic+0x127
> _mtx_lock_sleep(c9faf2b8,c9efa870,0,c06e20f4,5db) at _mtx_lock_sleep+0x35
> _mtx_lock_flags(c9faf2b8,0,c06e20f4,5db) at _mtx_lock_flags+0x95
> get_pv_entry(c9f519f0,82e7000,3cc405,bfc20b9c,f0261b9c) at get_pv_entry+0x10d
> pmap_insert_entry(c9f519f0,82e7000,c107f118) at pmap_insert_entry+0x12
> pmap_copy(c9f519f0,c9faf2b8,82e7000,1000,82e7000) at pmap_copy+0x22e
> vm_map_copy_entry(c9faf210,c9f51948,c9fc20cc,c9fe64c8) at vm_map_copy_entry+0x119
> vmspace_fork(c9faf210,c99b1ba0,c9f4ab04,c9f00d00,f0261c64) at vmspace_fork+0x1f8
> vm_forkproc(c9efa870,c9f4ab04,c9d8d6c0,14,c9f4ab6c,0,c06bf910,298,c0729de0,c06bf910,294) at vm_forkproc+0xb3
> fork1(c9efa870,14,0,f0261c7c,f0261d30) at fork1+0xe15
> fork(c9efa870,f0261d04,c9fba000,c,c9efa870) at fork+0x18
> syscall(3b,3b,bfbf003b,ffffffff,813cdf0) at syscall+0x27e
> Xint0x80_syscall() at Xint0x80_syscall+0x1f
> --- syscall (2, FreeBSD ELF32, fork), eip = 0x2816de5b, esp = 0xbfbcda8c, ebp = 0xbfbcdaa8 ---
> db> show alllocks
> Process 31193 (csh) thread 0xc9efb1b0 (102214)
> exclusive sleep mutex vm object (standard object) r = 0 (0xc9beeba0) locked _at_ vm/vm_fault.c:686
> exclusive sx user map r = 0 (0xc9faeca4) locked _at_ vm/vm_map.c:2993
> Process 31187 (csh) thread 0xc9efa870 (102219)
> exclusive sleep mutex pmap r = 0 (0xc9faf2b8) locked _at_ i386/i386/pmap.c:2355
> exclusive sleep mutex pmap r = 0 (0xc9f519f0) locked _at_ i386/i386/pmap.c:2354
> exclusive sleep mutex vm page queue mutex r = 0 (0xc0783e9c) locked _at_ i386/i386/pmap.c:2352
> exclusive sx user map r = 0 (0xc9faf254) locked _at_ vm/vm_map.c:2485
> db>

Looks like it locked the two pmap's in pmap_copy(), and while trying to get
a PV entry for the dst_pmap it tried to reclaim a pv entry from a page in
the src_pmap.  Hopefully Alan will have a good idea. :)

-- 
John Baldwin <jhb_at_FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org