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 > mtc0_tlbw_hazard > tlbwr # write random tlb entry > + nop > tlbw_eret_hazard > eret # return from trap > END(except_vec0_r4000) 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. Maciej
