Takao Shinohara wrote:

> [[ current core-dump problems and explaination of kernel pte deleted ]]

It appears that I've blamed the wrong part of the jumbo commit for my
problem - my apologies for this.  I think I had rebooted the wrong
kernel after changing the pte flags - I currently have 9 kernels in my
root directory :-(

This time however (I've double checked) I do think I've found the cause
of the problem:

	Index: mips/mips_machdep.c
	===================================================================
	RCS file: /cvsroot/syssrc/sys/arch/mips/mips/mips_machdep.c,v
	retrieving revision 1.55
	retrieving revision 1.56
	diff -p -u -r1.55 -r1.56
	--- mips_machdep.c      1999/09/24 00:37:52     1.55
	+++ mips_machdep.c      1999/09/25 00:00:39     1.56
	@@ -233,7 +241,7 @@ mips3_ConfigCache()
		mips_L1DCacheLSize = MIPS3_CONFIG_CACHE_L1_LSIZE(config,
		    MIPS3_CONFIG_DB);
	 
	-       mips_CacheAliasMask = (mips_L1DCacheLSize - 1) & ~(NBPG - 1);
	+       mips_CacheAliasMask = (mips_L1DCacheSize - 1) & ~(NBPG - 1);
	 
		/*
		 * Clear out the I and D caches.

Problems with the cache would explain random core dumps.  It also
accounts for something else I've noticed while tracking this down - the
system is extremely sluggish with the change in place.  For example, the
time for a "make" of a kernel when only mips_machdep.c has been touched
is:

	22.109u 15.237s 1:16.91 48.5%   0+0k 782+671io 1239pf+0w

using mips_L1DCacheLSize and

	177.882u 15.729s 3:51.86 83.4%  0+0k 781+680io 1239pf+0w

using mips_L1DCacheSize.  Cache problems would also explain this speed
problem.

From my reading of the comments in mips/pmap.c and the section on cache
aliasing in "See MIPS Run", it sounds like with the change we're now
not caching any page that when entered into the physical to virtual map
table that's virtual address matches any other page that's already in
the table, instead of just if the cache indexes match.  Does this sound
right?

Simon.