RE: Panics instead of Hard Locks
On 09-Nov-2002 Joel M. Baldwin wrote: Since going from a SMP to nonSMP kernel the Hard Locks don't seem to be happening. However I'm getting panics. I've gotten 4 'sleeping thread owns a mutex' panics and one each of 'Assertion i != 0 failed at ../../../kern/subr_witness.c:669' and 'Duplicate free of item 0xc3895cc0 from zone 0xc0ea63c0(VMSPACE)' More info follows. I finally got a debugger kernel built so I'll have even more info after the next panic. Let me know what I can do to help. -- panic: Assertion i != 0 failed at ../../../kern/subr_witness.c:669 Debugger(panic) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 db bt No such command db x Debugger+0x54: 29401d87 db t Debugger(c038693f,c03f6020,c0389a7b,cd2e2b00,1) at Debugger+0x54 panic(c0389a7b,c0389cee,c038993f,29d,cd2e2b64) at panic+0xab witness_lock(c03c29a0,8,c0386f4e,134,c0385a95) at witness_lock+0x513 _mtx_lock_flags(c03c29a0,0,c0386f4e,134,cd2e2b90) at _mtx_lock_flags+0xb1 msleep(c265d504,c03f4974,44,c039acd9,0) at msleep+0x644 acquire(c265d504,100,600,e3,5) at acquire+0xa7 lockmgr(c265d504,2,0,c0eadea0,cd2e2c2c) at lockmgr+0x378 _vm_map_lock_read(c265d4c8,c039ad3c,153,c0385a95,c265c700) at _vm_map_lock_read+0x5b vmspace_swap_count(c265d4c8,0,c039c4d2,493,0) at vmspace_swap_count+0x29 vm_pageout_scan(0,0,44,c039c590,1f4) at vm_pageout_scan+0xa48 vm_pageout(0,cd2e2d48,c0384133,354,0) at vm_pageout+0x262 fork_exit(c03163b0,0,cd2e2d48) at fork_exit+0xa5 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd2e2d7c, ebp = 0 --- *sigh*, This is a bogus assertion and my fault. I'll fix it. Thanks! -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Panics instead of Hard Locks
Since going from a SMP to nonSMP kernel the Hard Locks don't seem to be happening. However I'm getting panics. I've gotten 4 'sleeping thread owns a mutex' panics and one each of 'Assertion i != 0 failed at ../../../kern/subr_witness.c:669' and 'Duplicate free of item 0xc3895cc0 from zone 0xc0ea63c0(VMSPACE)' The 'Duplicate free' can be caused by a race between swapout_procs() and kern_exit()+wait1(). The enclosed patch might help. Disabling swapping (sysctl vm.swap_enabled=0) can also help. - Tor Egge Index: sys/kern/kern_exit.c === RCS file: /home/ncvs/src/sys/kern/kern_exit.c,v retrieving revision 1.184 diff -u -r1.184 kern_exit.c --- sys/kern/kern_exit.c15 Oct 2002 00:14:32 - 1.184 +++ sys/kern/kern_exit.c10 Nov 2002 17:58:39 - -285,7 +285,7 * Can't free the entire vmspace as the kernel stack * may be mapped within that space also. */ - if (--vm-vm_refcnt == 0) { + if (vm-vm_refcnt == 1) { if (vm-vm_shm) shmexit(p); pmap_remove_pages(vmspace_pmap(vm), vm_map_min(vm-vm_map), Index: sys/vm/vm_map.c === RCS file: /home/ncvs/src/sys/vm/vm_map.c,v retrieving revision 1.271 diff -u -r1.271 vm_map.c --- sys/vm/vm_map.c 9 Nov 2002 21:26:49 - 1.271 +++ sys/vm/vm_map.c 10 Nov 2002 17:59:40 - -314,11 +317,9 struct vmspace *vm; GIANT_REQUIRED; - if (p == p-p_vmspace-vm_freer) { - vm = p-p_vmspace; - p-p_vmspace = NULL; - vmspace_dofree(vm); - } + vm = p-p_vmspace; + p-p_vmspace = NULL; + vmspace_free(vm); } /*
Re: Panics instead of Hard Locks
If there's a race why hasn't it been fixed in the main tree? A swap issue makes sense. If I've been down long enough I get swamped with email when I come back up. A bug in the latest procmail yields 130M processes that fill up swap and make the system be swap bound. The solution is the following patch to procmail. http://www.rosat.mpe-garching.mpg.de/mailing-lists/procmail/2002-04/ms g00248.html --On Sunday, November 10, 2002 7:03 PM + [EMAIL PROTECTED] wrote: Since going from a SMP to nonSMP kernel the Hard Locks don't seem to be happening. However I'm getting panics. I've gotten 4 'sleeping thread owns a mutex' panics and one each of 'Assertion i != 0 failed at ../../../kern/subr_witness.c:669' and 'Duplicate free of item 0xc3895cc0 from zone 0xc0ea63c0(VMSPACE)' The 'Duplicate free' can be caused by a race between swapout_procs() and kern_exit()+wait1(). The enclosed patch might help. Disabling swapping (sysctl vm.swap_enabled=0) can also help. - Tor Egge To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message