I have understood the phenomenon, and I think this is a kernel's bug.
The real wrong place is not the judgement for condition "PG_dcache_dirty"
in function __update_cache( ).
in file mm/filemap.c and function filemap_nopage( ):
......
success:
/*
* Try read-ahead for sequential areas.
*/
if (VM_SequentialReadHint(area))
nopage_sequential_readahead(area, pgoff, size);
/*
* Found the page and have a reference on it, need to check sharing
* and possibly copy it over to another page..
*/
mark_page_accessed(page);
flush_page_to_ram(page);
return page;
......
flush_page_to_ram( ) has not been used for a long time, and in kernel 2.4.22
"include/asm-mips/cacheflush.h"
#define flush_page_to_ram(page) do { } while (0)
so the mapped page has not been flushed to ram, and the user space will not
know the latest data in the page.
the flush_page_to_ram( ) should be replaced by flush_dcache_page( ),
and if the flush_dcache_page( ) does not really flush the cache, it will set
the PG_dcache_dirty, and the real flush will be postponed to __update_cache( ).
and if there is not the flush_dcache_page( ) here, no one will set the PG_dcache_dirty,
and __update_cache( ) will not flush the page too, so the D-cache aliasing happens.
at last, when I replaced flush_page_to_ram( ) with flush_dcache_page( ), the internal compiler error disappeared.
I hope your problem will be solved by this way too. God bless you! :-)
This is probably just hiding your problem. flush_page_to_ram() is not used anymore.
P.
