In message <000001c29fe6$a34fb6c0$0d00a8c0@paq5>, you write: 

-> Rafal Boni rafal@attbi.com said;
-> 
-> > Also, the new R5000SC cache code seems broken (though
-> > Chris did warn about known issues with it), and gives the following
-> > output on my newly upgraded (to R5000SC) O2:
-> >
-> > CPU clock speed = 180.00Mhz*configging sdcache
-> > R5000/Rm5200 SCACHE
-> >
-> > Exception: <vector=ECC>
-> > Status register: 0x20000004<CU1,IPL=8,MODE=KERNEL>
-> > Error EPC: 0x802dc2c8
-> > CacheErr 0xe5000008<ER,EC,ED,EE,EI,SIDX=0x8,PIDX=0x0>
-> > --> ECC/Parity ERROR on the SysAD bus
-> > CRASH calling ecc_error_decode
-> 
-> - R5000 L2 cache is peculiar.  It's virtual address indexed, not the same as
-> R4000 nor RM527x/RM7000.

I know the first part, but I thought the R5000 actually *is* the same as
the Rm527x, even if neither is the same as Rm7k.  But now that I look at
the PMC docs, they do say (pretty clearly) physically indexed and tagged.

The R5k docs (well, NEC Vr5000 docs; I've been unable to find any MIPS
docs for the R5k) *do* say "virtually indexed/physically tagged" in the
"Cache Organization" chapter, but also say the following in the section
on the "CACHE" instruction (formatting tweaked by me, as it all pasted
as one giant long line):

	Chapter 3 CPU Instruction Set Summary 			(p. 73)

	The Index operation uses part of the virtual address to specify a
	cache block. For a primary cache of 32 KB with 32 bytes per tag,
	vAddr 13:5 specifies the block. In addition, vAddr 14 specifies
	which cache set to operate on. 

	For a secondary cache of 2^CACHEBITS bytes with 2^LINEBITS bytes
	per tag, pAddr[CACHEBITS ... LINEBITS] specifies the block. Index
	Load Tag also uses vAddr[LINEBITS... 3] to select the doubleword
	for reading parity. When the CE bit of the Status register is set,
	Hit WriteBack, Hit WriteBack Invalidate, Index WriteBack Invalidate,
	and Fill also use vAddr[LINEBITS ... 3] to select the doubleword
	that has its parity modified.

	[...]
	For Index operations (where the physical address is used to index
	the cache but need not match the cache tag) unmapped addresses may
	be used to avoid TLB exceptions. This operation never causes TLB
	Modified or Virtual Coherency exceptions. 

Maybe I'm missing something, but I think the above snippet says that the
secondary cache *is* actually physically indexed as described in the PMC
Rm52xx docs.

-> - I guess L2 cache is not properly initialized before use.  Then processor
-> gets confused and posts cache error exception (SIDX/PIDX value may
-> help).   Please comb through SMC-Sierra Knowledge Base.  I thought
-> there was a clue around there.

That was my guess as well, but I had been promising to put up some code and
unfortunately knew I wouldn't have a lot of time to play with it this week,
so I figured I'd put up what I had with the above caveat...

--rafal

----
Rafal Boni                                                     rafal@attbi.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill