linux-mips
[Top] [All Lists]

Re: HIGHMEM fix for r24k

To: "Ralf Baechle" <ralf@linux-mips.org>
Subject: Re: HIGHMEM fix for r24k
From: "Jon Fraser" <jfraser@broadcom.com>
Date: Fri, 24 Apr 2009 12:13:52 -0400
Cc: jfraser@broadcom.com, "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
In-reply-to: <20090424154349.GB3614@linux-mips.org>
Organization: Broadcom
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1240525424.15448.33.camel@chaos.ne.broadcom.com> <20090424154349.GB3614@linux-mips.org>
Reply-to: jfraser@broadcom.com
Sender: linux-mips-bounce@linux-mips.org
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





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