On Tue, Jun 12, 2007 at 09:50:00AM +0000, he@NetBSD.org wrote:
> 	Disassembly of pmap_activate() reveals:
> 
> (gdb) x/20i pmap_activate
> 0xc0467c7c <pmap_activate>:     push   %ebp
> 0xc0467c7d <pmap_activate+1>:   mov    %esp,%ebp
> 0xc0467c7f <pmap_activate+3>:   sub    $0x8,%esp
> 0xc0467c82 <pmap_activate+6>:   mov    0x8(%ebp),%edx
> 0xc0467c85 <pmap_activate+9>:   mov    %fs:0x4,%ecx
> 0xc0467c8c <pmap_activate+16>:  mov    0x10(%edx),%eax
> 0xc0467c8f <pmap_activate+19>:  mov    0x1c(%eax),%eax
> 0xc0467c92 <pmap_activate+22>:  cmp    0x14(%ecx),%edx
> 0xc0467c95 <pmap_activate+25>:  mov    (%eax),%eax
> 0xc0467c97 <pmap_activate+27>:  je     0xc0467c9c <pmap_activate+32>
> 0xc0467c99 <pmap_activate+29>:  leave  
> 0xc0467c9a <pmap_activate+30>:  ret    
> 0xc0467c9b <pmap_activate+31>:  nop    
> 0xc0467c9c <pmap_activate+32>:  cmpl   $0x0,0xc0(%ecx)
> 0xc0467ca3 <pmap_activate+39>:  jne    0xc0467cef <pmap_activate+115>
> 0xc0467ca5 <pmap_activate+41>:  cmpl   $0x0,0xc4(%ecx)
> 0xc0467cac <pmap_activate+48>:  je     0xc0467cd6 <pmap_activate+90>
> 0xc0467cae <pmap_activate+50>:  cmp    $0xc08d8780,%eax
> 0xc0467cb3 <pmap_activate+55>:  je     0xc0467cca <pmap_activate+78>
> 0xc0467cb5 <pmap_activate+57>:  mov    0x5c(%eax),%eax
> (gdb) x/20i
> 0xc0467cb8 <pmap_activate+60>:  mov    0x74(%edx),%edx
> 0xc0467cbb <pmap_activate+63>:  mov    %eax,0x60(%edx)
> 0xc0467cbe <pmap_activate+66>:  movl   $0x1,0xc0(%ecx)
> 0xc0467cc8 <pmap_activate+76>:  jmp    0xc0467c99 <pmap_activate+29>
> 0xc0467cca <pmap_activate+78>:  movl   $0x0,0xc0(%ecx)
> 0xc0467cd4 <pmap_activate+88>:  jmp    0xc0467c99 <pmap_activate+29>
> 0xc0467cd6 <pmap_activate+90>:  push   $0xc080baa0
> 0xc0467cdb <pmap_activate+95>:  push   $0x79a
> 0xc0467ce0 <pmap_activate+100>: push   $0xc080b9c0
> 0xc0467ce5 <pmap_activate+105>: push   $0xc07952a0
> 0xc0467cea <pmap_activate+110>: call   0xc0627e38 <__assert>
> 0xc0467cef <pmap_activate+115>: push   $0xc07aec2a
> 0xc0467cf4 <pmap_activate+120>: push   $0x799
> 0xc0467cf9 <pmap_activate+125>: jmp    0xc0467ce0 <pmap_activate+100>
> 0xc0467cfb <pmap_activate+127>: nop    
> 0xc0467cfc <pmap_reactivate>:   push   %ebp
> 0xc0467cfd <pmap_reactivate+1>: mov    %esp,%ebp
> 0xc0467cff <pmap_reactivate+3>: push   %edi
> 0xc0467d00 <pmap_reactivate+4>: push   %esi
> 0xc0467d01 <pmap_reactivate+5>: push   %ebx
> 
> 	and 0x39 = 57, so the last instruction above was where the
> 	problem hit.  This appears to be
> 
> 	pcb = &l->l_addr->u_pcb;
> 
> 	in pmap_activate() which is the source for these instructions.

I believe it is rather
	pcb->pcb_ldt_sel = pmap->pm_ldt_sel;

eax == pmap, edx == pcb.

This means that pmap == 0xdeadbeef. Moreover, at this point, pmap should
be the process' 0 (i.e. kernel's) pmap! (see
	/*
 	 * borrow proc0's address space.
 	 */
 	pmap_deactivate(l);
 	p->p_vmspace = proc0.p_vmspace;
 	pmap_activate(l);

in uvm_proc_exit)

So either somebody freed the kernel's vmspace, or for some reason
p->p_vmspace is not the process 0 vmspace.

Could you look if proc0.p_vmspace->vm_map.pmap is 0xdeadbeef at this point?