On Tue, May 18, 2004 at 01:17:38PM -0500, Bob Breuer wrote:
> > -----Original Message-----
> > From: firstname.lastname@example.org
> > [mailto:email@example.com]On Behalf Of Peter Horton
> > Sent: Friday, May 14, 2004 2:53 AM
> > To: wuming
> > Cc: firstname.lastname@example.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.
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().
BTW, I _think_ the last problem stilled exists in 2.6. We probably need
to use the reverse maping info to fix it.