>>>>> "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
