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; My highmem kernel now works. This is w/o discontiguous or sparsemem set. I do have two discontiguous banks of memory. I'm not sure of the best fix. Simple reordering of the the init code to set the variable before it gets used breaks other initialization. My kernel tree is a big mess right now and I'm back at 2.6.26 where the bug was introduce. As soon as I have 2.6.28 or 29 working, I'll post any more changes. Jon Fraser Broadcom