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

From: Jed Davis <jld@NetBSD.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/33234
Date: Tue, 11 Apr 2006 02:01:39 -0400

 This one is happening fairly frequently, and so I've determined (by
 chasing pointers by hand in ddb; ick) that, after the panic, the vmspace
 in question (ci->ci_curlwp->l_proc->p_vmspace) has been returned to the
 pool and deadbeef'ed.  And that clearly hasn't happened at the top of
 pmap_load, where it gets a valid pointer to the pmap (which has been
 destroyed by the time pmap_reference is reached).  (I also now have a
 core that's not potentially tainted by the double-panic on sync.)
 
 This really does seem like insufficient locking on the vmspace, as if
 one process thinks it's removed the last reference and destroys it while
 another is switching to it on the other CPU; except that doesn't make
 much sense in this context, assuming I understand the context correctly.