linux-mips-fnet
[Top] [All Lists]

Re: Indy crashes

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: Indy crashes
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Wed, 16 Feb 2000 01:13:37 +0100
Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>, linux@cthulhu.engr.sgi.com, linux-mips@fnet.fr, linux-mips@vger.rutgers.edu
In-reply-to: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com>
References: <006501bf7803$59855ad0$0ceca8c0@satanas.mips.com>
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

<Prev in Thread] Current Thread [Next in Thread>