Is this expected behaviour? :)


"yes and no".  yes, it's expected to be unstable.  but no, i don't
think we've seen that particular brand of unstable before now :)


hopefully fixes for hypersparc will be coming soon.  for now you
can get a running system by disabling the icache.  see my patch
below (a repost).


.mrg.


Index: cache.c
===================================================================
RCS file: /cvsroot/src/sys/arch/sparc/sparc/cache.c,v
retrieving revision 1.77
diff -p -r1.77 cache.c
*** cache.c	20 Jan 2003 22:15:54 -0000	1.77
--- cache.c	4 Feb 2003 00:10:46 -0000
*************** hypersparc_cache_enable()
*** 224,229 ****
--- 224,235 ----
  	if (CACHEINFO.c_hwflush)
  		panic("cache_enable: can't handle 4M with hw-flush cache");
  
+ #if 1
+ ls = CACHEINFO.ic_linesize;
+ ts = CACHEINFO.ic_totalsize;
+ for (i = 0; i < ts; i += ls)
+   sta(i, ASI_ICACHETAG, 0);
+ #endif
  	/*
  	 * Enable instruction cache and, on single-processor machines,
  	 * disable `Unimplemented Flush Traps'.
*************** hypersparc_cache_enable()
*** 232,237 ****
--- 238,246 ----
  	v = HYPERSPARC_ICCR_ICE | (ncpu == 1 ? HYPERSPARC_ICCR_FTD : 0);
  #else
  	v = HYPERSPARC_ICCR_ICE | HYPERSPARC_ICCR_FTD;
+ #endif
+ #if 1
+ v = HYPERSPARC_ICCR_FTD;
  #endif
  	wrasr(v, HYPERSPARC_ASRNUM_ICCR);
  }