actually, on second thought, I was wrong.  the change below really
shouldn't be necessary.  pmap_clear_modify() needs to make sure there
aren't any dirty cache lines in a VAC, but the VAC on the ultrasparcs
is write-through, so there can't be any dirty cache lines in the VAC.
the real problem is something else.

-Chuck


On Thu, Aug 22, 2002 at 10:23:16AM -0700, Andrey Petrov wrote:
> On Thu, Aug 22, 2002 at 11:47:53AM +0200, Hubert Feyrer wrote:
> >
> > Using the latest snapshot from releng.netbsd.org, I get lots of "signal
> > 11"s during compilation. I'v replaced the machine's RAM (4*256 -> 4*64),
> > but that didn't make any differences.
> > 
> 
> I'm not sure if that hme or not but the following patch fixed
> 'signal 11' during NFS build for me. I have some theory about
> aliased shared pages, but it's just guess with no prove at this 
> point.
> 
> 	Andrey
> 
> Index: pmap.c
> ===================================================================
> RCS file: /cvsroot/syssrc/sys/arch/sparc64/sparc64/pmap.c,v
> retrieving revision 1.125
> diff -u -p -r1.125 pmap.c
> --- pmap.c      2002/08/12 12:04:31     1.125
> +++ pmap.c      2002/08/22 17:14:52
> @@ -2805,6 +2805,7 @@ pmap_clear_modify(pg)
>                                 changed |= 1;
>                         pv->pv_va &= ~(PV_MOD);
>                         simple_unlock(&pv->pv_pmap->pm_lock);
> +                       dcache_flush_page(pa);
>                 }
>         splx(s);
>         pv_check();