Subject: Re: Indy crashes

From: "Kevin D. Kissell" <[email-masked]>
Date: Tue, 15 Feb 2000 23:23:49 +0100

>> The problem may be in the assumption made even in the
>> most recent 2.3.x code that a hit-writeback-invalidate cache
>> operation on the secondary cache automagically affects the
>> primary.  That's the way it is on the R4000/4400, but that's
>
>In that case it doesn't affect the NEC DDB Vrc-5074, since there's no L2.

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.

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.

            Regards,

            Kevin K.
__

Kevin D. Kissell
MIPS Technologies European Architecture Lab
[email-masked]
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 16 Feb 2000 01:13:37 +0100

> and the tlbwr.  It should be OK for an R4000, but not for 

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.

> mtc0 and the branch (sigh) to see if that stabilizes 

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

---

From: "William J. Earl" <[email-masked]>
Date: Tue, 15 Feb 2000 17:16:45 -0800 (PST)

> On Tue, Feb 15, 2000 at 11:23:49PM +0100, Kevin D. Kissell wrote:
...
 > >          tlbwr                                  # write random tlb entry
...
 > but as I understood them the above code should also work just perfect

      There is a need for a workaround on the R5000 for a "bad $badvaddr" 
problem.  The except_vec0_r45k_bvahwbug() variation does not appear to be
enabled for the R5000.  (It should not be needed for the RM7000 or the RM5271.)

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 16 Feb 2000 02:23:34 +0100

> enabled for the R5000.  (It should not be needed for the RM7000 or the RM5271.)

I don't have this bug in my erratas documented, can you elaborate on it?

  Ralf

---

From: "William J. Earl" <[email-masked]>
Date: Tue, 15 Feb 2000 17:46:06 -0800 (PST)

...
 > I don't have this bug in my erratas documented, can you elaborate on it?

     Sometimes you get a utlbmiss exception when there is already matching
TLB entry.  If you then blindly drop in the TLB entry, you get a duplicate,
which leads to Bad Things (tm).  The workaround is to probe for a duplicate,
and skip the tlbwr if an entry already exists.  It should be enabled on any
real R5000.  

    This is from the R5000 Errata list of 30 October 1997:

----------------------------------------------------------------------
3.  An erroneous JTLB miss exception will be taken under
    these conditions. 

    a) An instruction which does not cause an exception or
       stall is 8 bytes away from the end of a page.
    b) A load or store instruction is the last instruction of that page.
    c) The load/store target address has a matching but invalid
       JTLB entry
    d) The next sequential page is not mapped in the JTLB

    In this situation, when the load/store instruction is executed,
    a JTLB invalid exception should be taken, instead a JTLB miss
    exception is incorrectly taken. If the exception handler
    does a random TLB write to resolve the exception, this will in 
    general insert a duplicate TLB entry for each erroneous exception.
    If the first instruction is a jump or branch, this will cause
    an infinite loop of JTLB miss exceptions to occur upon the return
    from the exception handler.  Otherwise, there will be only one
    erroneous exception, followed by a correct exception, leaving
    one duplicate entry in the TLB.

    A software fix is for the JTLB miss handler to detect this situation,
    by probing for a matching TLB entry (treating a hit as being this case),
    ignore the JTLB miss and treat the exception as an JTLB invalid exception.

    Errata 3 is fixed in Rev 2.0.
----------------------------------------------------------------------

      It is not clear to me that Errata 3 is fixed in all cases in Rev 2.*,
so IRIX has the workaround enabled for all R5000 revisions.

     In Linux, just use except_vec0_r45k_bvahwbug() for any R5000.