>>>>> "ralf" == Ralf Baechle <ralf@linux-mips.org> writes:
ralf> On Fri, Mar 28, 2003 at 06:51:57PM +0100, Maciej W. Rozycki wrote:
>> > flush_cache_mm can use __flush_cache_all.
>>
>> Wrong, it should use r4k_flush_pcache_all() unconditionally, but I'm told
>> such a setup triggers a bug somewhere, that needs to be tracked down
>> before committing that change to the CVS.
ralf> Now that the problem is mentioned on the list lemme elaborate a bit. The
ralf> problem mentioned only affects R4000SC and R4400SC processors.
ralf> Flush_cache_mm is only used when a mm is either copied on fork or when
ralf> it's finally destroyed. Because the S-cache is is physically indexed
ralf> and the P-cache is refilled from the S-cache if data should be still in
ralf> there we don't need to flush the S-cache ever for any of the mm's
ralf> cacheflushing functions. So the observation that things are only
ralf> working properly if we do flush the S-cache also suggest we're either
ralf> having a bug elsewhere in the cache code or we're hitting a hardware
ralf> problem.
Just to add some more data points. flush_cache_mm() is only called
from two places:
- kernel/fork.c::dup_mmap()
- mm/mmap.c::exit_mmap()
I just changed flush_cache_mm() to be r4k_flush_pcache_all() and put
after the two calls a __flush_cache_all(). As expected everything
worked :)
Now if I removed teh __flush_cache_all() for any of the callers,
everything goes well. But if I remove it for both of them things
crashed during boot. I am looking at the code of both functions, and
can't see a good reason for them to fail :(
Does that ring any bells on you?
I am still investigating that one.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
|