On Thu, Apr 23, 2009 at 06:23:44PM -0400, Jon Fraser wrote: > For all you guys working on HIGMEM. > > I found a bug that was keeping HIGHMEM from working on mips 24k > processors starting at 2.6.26. > > > 2008-04-28 Chris Dearman [MIPS] Allow setting of the cache attribute at > run ... > > This commit introduces the variable _page_cachable_default, which > defaults to zero. > > arch/mips/mm/cache.c: > unsigned long _page_cachable_default; > > The variable is used to create the prototype PTE for __kmap_atomic in > arch/mips/mm/init.c:kmap_init. > > The variable is initialized in arch/mips/mm/c-r4k.c:coherency_setup. > > Unfortunately, the variable is used before it is initialized properly. > As a result, all kmap_atomic PTE have the cache coherency algorithm mode set to 0. > Mode 0 is "cacheable, nocoherent, write-through, no write allocate". > This is not valid on my r24k and my not be on any r24k. > > The result is that writes to kmap_atomic pages get corrupted. This was confirmed > using a jtag probe, examining uncached memory, the D cache itself, and cached memory. > > I've changed the variable declaration to be: > unsigned long _page_cachable_default = _CACHE_CACHABLE_NONCOHERENT; There is no safe value of _page_cachable_default; it's all processor and even platform dependent. What you found is essentially an ordering bug so let's fix the ordering! Ralf
