Nice catch guys.  I did some sluthing in the pmem_map stuff months ago
looking for the problem but couldn't find the exact cause.  I'll keep my
fingers crossed that you guys have a handle on it.

:-)

--

J. Scott Kasten
Email: jsk AT tetracon-eng DOT net

"In most cases, all an argument proves
 is that two people were present......"

On Fri, 20 Oct 2000, Izumi Tsutsui wrote:

> 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
>