On Sat, 2 Oct 2004, Thiemo Seufer wrote:
> > The last problem happens only on r4000 and r4400, and occasionally
> > also shows up as "illegal instruction" or "unaligned access". It
> > turned out to be a broken TLB handler. I temporarily switched (for
> > 32bit kernels) from except_vec0_r4000 to except_vec0_r45k_bvahwbug.
> > This may cause an avoidable performance loss, but at least it allows
> > my R4400SC-200 (V6.0) Indy to run current 2.6 CVS.
> One more nop is enough to make it work. This should probably go in
> a hazard definition.
> --- arch/mips/mm/tlbex32-r4k.S 20 Jun 2004 23:52:17 -0000 1.1
> +++ arch/mips/mm/tlbex32-r4k.S 2 Oct 2004 20:36:29 -0000
> @@ -179,6 +179,7 @@
> P_MTC0 k1, CP0_ENTRYLO1 # load it
> tlbwr # write random tlb entry
> + nop
> eret # return from trap
I'd be inclined to add this nop to the tlbw_eret_hazard definition, but
it should really be processor-dependent.
According to the R4000/R4400 cp0 hazard dependency table, there is a
three-instruction delay between tlbwi/tlbwr and eret with respect to TLB
use and two-instruction one between tlbwi/tlbwr and the instruction
following eret for the R4600/R4700. Therefore, there should actually be
three nops there for the R4000/R4400 and one for the R4600/R4700. AFAIK
mtc0_tlbw_hazard acts as a way to simulate two nops for the R4000/R4400.
Still, tlbw_eret_hazard expands to nothing for non-RM9000 processors.
I think we should either handcode all handlers explicitly or build a
single one dynamically, like we do for copy_page()/clear_page(). For now,
I'll just add the missing nop directly to the handlers. Thanks for
working on it.