linux-mips
[Top] [All Lists]

HIGHMEM fix for r24k

To: "linux-mips@linux-mips.org" <linux-mips@linux-mips.org>
Subject: HIGHMEM fix for r24k
From: "Jon Fraser" <jfraser@broadcom.com>
Date: Thu, 23 Apr 2009 18:23:44 -0400
Organization: Broadcom
Original-recipient: rfc822;linux-mips@linux-mips.org
Reply-to: jfraser@broadcom.com
Sender: linux-mips-bounce@linux-mips.org
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




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