> Looking at the pmap.c log file I see that several patches related to 
> cacheing page-table entries have been pulled up.  I'll try backing out 
> some of those tonight unless someone can identify what is missing between 
> the branch and current, which doesn't seem to have this instability.

Last night I tried backing out all the pmap.c changes since 1.6 was 
released.  Unfortunately it turned out to be more complex than that, since 
there is more than one file affected (all the xxx_machdep.c file have to 
be fixed up as well), so I abandoned that for the moment.  I tried pulling 
up rev 1.104 onto the branch, but that had no effect.

So in desperation I built a -current kernel using as much of the 1.6.1 
world as I could get away with (the compiler is OK, but config and objcopy 
have to be from current) and booted that.  I only had it up for about half 
an hour before I had to come to work, but it looked to be stable.

So what does this tell us?

Assuming that a -current kernel is stable, that rules out the problem 
being in user-land (eg, ld.elf.so).  It also pretty much eliminates the 
likelihood of it being the compiler at fault.

I'll have another attempt to back out the pmap-related changes tonight.  
Is there any way to identify groups of changes with NetBSD's commit policy 
other than by trawling the commit logs in the mailing list archives?

R.