Date: Mon, 27 Mar 2006 13:23:43 -0500 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 pmap @ ../../../i386/i386/pmap.c:1499 Message-ID: <200603271323.46073.jhb@freebsd.org> In-Reply-To: <20060327014552.GA37946@xor.obsecurity.org> References: <20060327014552.GA37946@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 26 March 2006 20:45, Kris Kennaway wrote: > panic: _mtx_lock_sleep: recursed on non-recursive mutex pmap @ ../../../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 @ ../../../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 @ vm/vm_fault.c:686 > exclusive sx user map r = 0 (0xc9faeca4) locked @ vm/vm_map.c:2993 > Process 31187 (csh) thread 0xc9efa870 (102219) > exclusive sleep mutex pmap r = 0 (0xc9faf2b8) locked @ i386/i386/pmap.c:2355 > exclusive sleep mutex pmap r = 0 (0xc9f519f0) locked @ i386/i386/pmap.c:2354 > exclusive sleep mutex vm page queue mutex r = 0 (0xc0783e9c) locked @ i386/i386/pmap.c:2352 > exclusive sx user map r = 0 (0xc9faf254) locked @ 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@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?200603271323.46073.jhb>