In <200010181113.e9IBD6x02639@mirage.ceres.dti.ne.jp>
I wrote:

> In <Pine.BSF.4.21.0010170945410.71687-100000@simon.baymoo.org>
> jeremy@baymoo.org wrote:
> 
> > Can someone do a test for me and anyone uncomment the 'pmap_lock(pmap);'
> > and 'pmap_unlock(pmap);' lines that occur in both the sun3x
> > pmap_reference() and pmap_dereference()?  As usual, a full make build of
> > the source tree should suffice as a stress test.
> 
> It looks some more macros and initialization are needed.
> Is the attached patch correct?

Ah, now I notice an obvious bug other than missing pmap_lock().

pmap->pm_refcount is _not_ initialized to 1 in pmap_pinit().
So pmap_dereference() which is called from pmap_destroy()
would return a negative value, then most pmap structures would
never be free()'d. I think that's the problem.

I'll try another make build with newer kernel.
---
Izumi Tsutsui
tsutsui@ceres.dti.ne.jp

Index: pmap.c
===================================================================
RCS file: /cvsroot/syssrc/sys/arch/sun3/sun3x/pmap.c,v
retrieving revision 1.52
diff -u -r1.52 pmap.c
--- pmap.c	1999/12/17 08:10:59	1.52
+++ pmap.c	2000/10/19 14:43:55
@@ -2571,6 +2571,7 @@
 	bzero(pmap, sizeof(struct pmap));
 	pmap->pm_a_tmgr = NULL;
 	pmap->pm_a_phys = kernAphys;
+	pmap->pm_refcount = 1;
 }
 
 /* pmap_release				INTERFACE