On Wed, Oct 14, 1998 at 06:13:31PM +0200, Ulf Carlsson wrote:

Can you please explain to me what the fixes actually needed for the SC were? I
am quite interested.

Ok, here we go again.  Attached the patch which I checked in yesterday.
Should tell most easy what I've changed:

 - The VCE exceptions need special handling in the general exception vector.
   In particular it's important that we cannot do any cached loads / stores
   before we've brought caches back to a sane state.  So all the old handlers
   in entry.S and traps.c had to go away.
 - Some of the cache operations defined in r4xx0.c use Hit_*_SD operations to
   work on the caches.  These have the nice property that they will also
   invalidate any primary cache line in both icache and dcache that maps to
   the affected secondary cache line.  In other words code sequences like

       blast_dcache16_page(start);
       if(text)
               blast_icache16_page(start);
       blast_scache16_page(start);

   can simply be replaced by

       blast_scache16_page(start);

   This change does not represent any kind of bug, it's just important
   performance work because cache instructions are expensive even if there
   is no work to do, that is no writebacks or invalidates.  Aside due to the
   massive loop unrolling used in that code we just saved us close to 10kb
   in kernel size.
 - We had code to support a cache configuration with a data cache linesize
   of 32 bytes and second level linesize of 16 bytes.  Configurations where
   the second level linesize is smaller than the primary cache linesize are
   however forbidden, so away with the code.
 - As you remember I disabled the use of the Create_Dirty_Excl_D based
   versions of clear_page and copy_page for R4000 / R4400 SC and MC versions
   as part of the first round of SC fixes.  Now I implemented a set of four
   routines optimized for each possible second level cache linesize.  Right
   now there are only new variants of clear_page; copy_page will come asap.
   I attempted to implement optimized variants using both Create_Dirty_Excl_SD
   and Create_Dirty_Excl_D in clear_page but the resulting kernel crashed
   immediately.  Not shure what the cause is.
 - The untested draft variant of head.S which I mailed to you was not word-
   aligning the address used to index the primary cache tag array.  The
   effect is somewhat hidden, just occasionally programs will die with
   SIGBUS.  No idea why this is necessary.
 - One structure in sgiseeq needed extra padding.  This was not an actual
   SC-bug; the driver would have failed on any machine with cachelines
   larger than 64 bytes.  I increased the number of fill bytes to make the
   driver work with 128 byte linesized caches which is the largest available
   for the IP22.

Somebody asked me why the general exception handler or the VCED / VCEI
exception handlers never crash with a VCE exception resulting in a infinite
loop.  First of all don't do any loads or stores before we've serviced a
VCED / VCEI exception, so we can never catch any VCED exception.  Second,
a VCED / VCEI exception will only occur in case of both a primary and
secondary cache hit where the second level cache virtual index is different
from the actual virtual address' index bits.  In normal live this will
never happen since the exception handlers are only accessed via KSEG0 but
never mapped.  In other words mmaping /dev/mem and just _reading_ the wrong
RAM addresses is a safe way to crash the machine.  Well, you're not supposed
to even try that.

  Ralf