Re: problems on D-cache alias in 2.4.22

[Jun Sun <jsun@mvista.com>]

On Tue, May 18, 2004 at 01:17:38PM -0500, Bob Breuer wrote:
> 
> > -----Original Message-----
> > From: linux-mips-bounce@linux-mips.org
> > [mailto:linux-mips-bounce@linux-mips.org]On Behalf Of Peter Horton
> > Sent: Friday, May 14, 2004 2:53 AM
> > To: wuming
> > Cc: linux-mips@linux-mips.org
> > Subject: Re: problems on D-cache alias in 2.4.22
> > 
> > 
> > wuming wrote:
> > 
> ...
> > > at last, when I replaced flush_page_to_ram( ) with 
> > flush_dcache_page( ),
> > > the internal compiler error disappeared.
> > >
> ...
> > 
> > This is probably just hiding your problem. flush_page_to_ram() is not 
> > used anymore.
> > 
> > P.
> > 
> > 
> 
> Changing that same place also fixes my problem.  

<snip>

Like others suggested, this is not the right fix.  flush_page_to_ram()
is correctly nullified.  Its job should be done somewhere else
by other routines.

Here are a couple of random ideas for finding the true root cause:

. If a page is shared by multiple user processes, make sure either the CPU
  does not have d-cache alaising problem (i.e., cache way size is 4KB or less)
  or their virtual addresses lie on the "same color strip" of the d-cache.
  In other words, they would be cached in the same cache way.

. If a page is modified by kernel and accessed by user land, make sure a 
  flush_dcache_page() is called right after the modifying.

. If a page is modified by userland and accessed by kernel, I _think_ currently
  kernel would still do a flush_dcache_page() call.  However, this won't
  work on MIPS because the cache at user virtual addresses are not flushed.
  Either try to flush with user virtual address, or do a flush_cache_all(). *ick*

BTW, I _think_ the last problem stilled exists in 2.6.  We probably need
to use the reverse maping info to fix it.

Jun