On Wed, 3 Nov 1999, Takao Shinohara wrote:

> Takao Shinohara <shin@sm.sony.co.jp> writes:
> > 
> > I think I found the cause of the core-dump problem.
> > 
> > In function mips3_FlushDCache(), secondary cache is flushed by virtual
> > address. But we need physical address to flush secondary cache
> > properly.
> 
> Simon, could you test this patch?
> 
> I can't test it myself, because I have no R4000/R4400 machine with
> secondary cache.

  Actually, I'm considering fixing this particular problem in a different
manner.  The DECstations with the R4x00 CPU have secondary cache, and the
CPU can detect cache coherency problems and there's an exception handler
which flushes the appropriate cache lines which caused the execption.
Simon and I have successfully run -current on our DECstations with the
cache-inhibit code disabled.  The fix I am contemplating is to only check
for cache aliases conflicts if there is no secondary cache, and let the
virtual coherency exception handler fix up coherency problems if secondary
cache is present.  This yields much better performance for systems with
secondary cache.

  Systems without secondary cache may still see poor performance with the
-current ld.elf_so.  If the problem with mmap() in ld.elf_so can be fixed
to allow properly aligned mappings, the performance degradation of these
systems will improve.  [Cache alias mappings from vmapbuf for physio will
still suffer, but I have some fixes to help that as well.]

  The cache flushing on the R4x00 does need to be fixed though, and the
suggested fix is probably better than what I have been doing.  Removing
the secondary cache flushing from MachFlushDCache() means that all the
other calls to MachFlushDCache need to have separate secondary cache
flushes.  I haven't looked at all these yet, so I'm not sure if the
physical address is easily available in all cases.

  I also dislike doing a flush by index, since that will flush all entries
indexed by the specified virtual address, including entries that don't
match the specified virtual address.  A Hit_Flush_Invalidate operation
would be the preferred method, but that requires a valid mapping of the
virtual address - which may not always be possible (a specific example
might be when ptrace is modifying another process's page to insert/remove
a breakpoint).  I think I have a way to do this relatively painlessly, but
I need to refresh my memory on the MIPS memory managment and cache
operation.

Michael
--
Michael L. Hitch			mhitch@montana.edu
Computer Consultant
Information Technology Center
Montana State University	Bozeman, MT	USA