On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote:
> If it isn't the cache, and it tracks the CPU type, the next thing
> I suspect is a pipe hazard. The R5000 manual states that there
> should be "at least two integer instructions between" any
> instruction modifying the PageMask, EntryHi, or EntryLo[01]
> registers and the subsequent tlbw[ir] or tlbp. That's different
> from the R4000. In the current Linux arch/mips/head.S file,
> this interval does not seem to be respected by any of the TLB
> miss handlers. Indeed, the default except_vec0_r4000 handler,
> which I believe is what is used if an R5000 is detected, has
> the sequence
>
> mtc0 k1, CP0_ENTRYLO1 # load it
> b 1f
> tlbwr # write random tlb entry
> 1:
> nop
> eret
>
> wherin the purpose of the branch is obscure (I imagine
> it fixed a bug seen somewhere on some CPU but it
> makes me rather queasy) but wherein in any case we
> do not seem to be assured 2 issues between the mtc0
> and the tlbwr. It should be OK for an R4000, but not for
> an R5000.
No, it's not a bug workaround. The reason for this branch is that the
R4000 and R4400 have a penalty of three cycles for a taken branch. So
the branch above is equivalent with
mtc0 k1, CP0_ENTRYLO1
nop
tlbwr
nop
nop
nop
eret
Funky trick, isn't it? I don't have the the R4600 / R5000 docs at hand
but as I understood them the above code should also work just perfect
for them.
> So someone with the ability to reproduce the R5000
> problem should really try sticking a nop between the
> mtc0 and the branch (sigh) to see if that stabilizes
> the system.
Talking about CPU bugs - the R5230 and maybe it's relatives needs a nasty
workaround. I think I only put the workaround into the Cobalt kernel.
Of course IDT doesn't admit that this bug even exists ...
Ralf
|