[Top] [All Lists]

Re: HIGHMEM fix for r24k

To: Jon Fraser <>
Subject: Re: HIGHMEM fix for r24k
From: Ralf Baechle <>
Date: Fri, 24 Apr 2009 17:43:49 +0200
Cc: "" <>
In-reply-to: <>
Original-recipient: rfc822;
References: <>
User-agent: Mutt/1.5.18 (2008-05-17)
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!


<Prev in Thread] Current Thread [Next in Thread>