Re: kern/37993: panic: lockmgr: locking against myself (netbsd-4.0_STABLE)

[Andrew Doran <ad%netbsd.org@localhost>]

The following reply was made to PR kern/37993; it has been noted by GNATS.

From: Andrew Doran <ad%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/37993: panic: lockmgr: locking against myself 
(netbsd-4.0_STABLE)
Date: Thu, 28 Feb 2008 23:10:28 +0000

 On Thu, Feb 28, 2008 at 08:45:02PM +0000, Greg A. Woods wrote:
 
 >  last locked: /rest/work/woods/m-NetBSD-4/sys/uvm/uvm_map.c:1021
 >  last unlocked: /rest/work/woods/m-NetBSD-4/sys/uvm/uvm_map.c:1011
 >  kernel_map_store(c09822f4,3f303fd,0,c0a67284,0) at 0xc0a50820
 >  Stopped in pid 2264.2 (apcupsd) at      netbsd:cpu_Debugger+0x4:        
 > popl    %ebp
 >  db{0}> trace
 >  cpu_Debugger(d98c25d0,1,ffff,c0959b17,c041c0e0) at netbsd:cpu_Debugger+0x4
 >  _simple_lock(c0a50924,c09818f0,1a1,d98c2680,18c2704) at 
 > netbsd:_simple_lock+0x331
 >  uvm_map_prepare(c0a50820,c0000000,20000,0,ffffffff) at 
 > netbsd:uvm_map_prepare+0x329
 >  uvm_map(c0a50820,d98c26e4,20000,0,ffffffff) at netbsd:uvm_map+0xc0
 >  km_vacache_alloc(c0a50980,0,525,206,c09d9bf4) at 
 > netbsd:km_vacache_alloc+0x67
 >  pool_grow(c0a509f0,c0988ec4,3a7,3a4,977) at netbsd:pool_grow+0x4c
 >  pool_get(c0a50980,0,d98c279c,202,d98c279c) at netbsd:pool_get+0x12f
 >  uvm_km_alloc_poolpage_cache(c0a50820,0,525,206,c09d9bf4) at 
 > netbsd:uvm_km_alloc_poolpage_cache+0x59
 >  pool_grow(c0a51ef0,c0988ec4,3a7,3a4,d992) at netbsd:pool_grow+0x4c
 >  pool_get(c0a51e80,0,d98c285c,c0433942,0) at netbsd:pool_get+0x12f
 >  sadata_upcall_alloc(0,58,d98c285c,202,c0a5094c) at 
 > netbsd:sadata_upcall_alloc+0x21
 >  ltsleep(c0a5087c,4,c092e1f9,0,c0a50924) at netbsd:ltsleep+0x552
 >  uvm_map_prepare(c0a50820,c0000000,20000,0,ffffffff) at 
 > netbsd:uvm_map_prepare+0x1b4
 >  uvm_map(c0a50820,d98c2964,20000,0,ffffffff) at netbsd:uvm_map+0xc0
 >  km_vacache_alloc(c0a50980,2,525,202,c09d9bf4) at 
 > netbsd:km_vacache_alloc+0x67
 >  pool_grow(c0a509f0,c0988ec4,3a7,3a4,cffe7594) at netbsd:pool_grow+0x4c
 >  pool_get(c0a50980,2,0,202,0) at netbsd:pool_get+0x12f
 >  uvm_km_alloc_poolpage_cache(c0a50820,1,525,202,c09d9bf4) at 
 > netbsd:uvm_km_alloc_poolpage_cache+0x59
 >  pool_grow(c0a6ccf0,c0988ec4,3a7,3a4,0) at netbsd:pool_grow+0x4c
 >  pool_get(c0a6cc80,2,80f,3a4,d002c694) at netbsd:pool_get+0x12f
 >  pool_cache_get_paddr(c0a6cb20,2,0,0,0) at netbsd:pool_cache_get_paddr+0x15b
 >  pmap_create(d002c794,0,bfc00000,41,d002c690) at netbsd:pmap_create+0xe2
 >  uvmspace_init(d002c690,0,0,bfc00000,d9848f80) at netbsd:uvmspace_init+0x75
 >  uvmspace_alloc(0,bfc00000,d9848f80,c09818f0,1c2) at 
 > netbsd:uvmspace_alloc+0x3a
 >  uvmspace_fork(d9848e7c,d97f2204,48,d98b9020,d98b9020) at 
 > netbsd:uvmspace_fork+0x116
 >  uvm_proc_fork(d97f2204,d98b9020,0,246,c09d9bf4) at netbsd:uvm_proc_fork+0x23
 >  fork1(d97ef4bc,0,14,0,0) at netbsd:fork1+0x2f9
 >  sys_fork(d97ef4bc,d98c2c48,d98c2c68,813811f,8138000) at netbsd:sys_fork+0x45
 >  syscall_plain() at netbsd:syscall_plain+0x1a8
 >  --- syscall (number 2) ---
 >  0x80f6613:
 >  db{0}> call simple_lock_dump()
 >  all simple locks:
 >  0xc0a67274 CPU 0 /rest/work/woods/m-NetBSD-4/sys/kern/kern_lock.c:1476
 >  0xc0a50924 CPU 0 /rest/work/woods/m-NetBSD-4/sys/uvm/uvm_map.c:1021
 >  0x80000000
 
 This one is a design defect in the SA thread implementation and is fixed in
 current with 1:1 threads. The original panic is different and is a problem
 in the x86 pmap.
 
 Andrew