On Fri, 2009-04-24 at 08:43 -0700, Ralf Baechle wrote: > 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 > That's why I haven't proposed a fix yet. But there are other people dealing with the same HIGHMEM issues and I wanted them to know about the problem. Jon
