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
can simply be replaced by
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.
Description: Text document