On Tue, May 18, 2004 at 01:17:38PM -0500, Bob Breuer wrote: > > > -----Original Message----- > > From: linux-mips-bounce@xxxxxxxxxxxxxx > > [mailto:linux-mips-bounce@xxxxxxxxxxxxxx]On Behalf Of Peter Horton > > Sent: Friday, May 14, 2004 2:53 AM > > To: wuming > > Cc: linux-mips@xxxxxxxxxxxxxx > > 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
