linux-mips
[Top] [All Lists]

Re: Patches for 34K APRP

To: Ralf Baechle <ralf@linux-mips.org>
Subject: Re: Patches for 34K APRP
From: "Kevin D. Kissell" <kevink@mips.com>
Date: Thu, 17 Apr 2008 15:38:00 +0200
Cc: linux-mips@linux-mips.org
In-reply-to: <20080417124319.GA31453@linux-mips.org>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4805FFE6.5080903@mips.com> <20080417124319.GA31453@linux-mips.org>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Thunderbird 2.0.0.12 (Windows/20080213)
Ralf Baechle wrote:
On Wed, Apr 16, 2008 at 03:32:22PM +0200, Kevin D. Kissell wrote:

 arch/mips/kernel/setup.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index f8a535a..a6a0d62 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -336,6 +336,10 @@ static void __init bootmem_init(void)
 #endif
                max_low_pfn = PFN_DOWN(HIGHMEM_START);
        }
+       /*
+        * Propagate final value of max_low_pfn to max_pfn
+        */
+       max_pfn = max_low_pfn;

That will be incorrect for systems with highmem.  So I think the right
fix is to replace all references to max_pfn in vpe.c with max_low_pfn.
Which will still be incorrect for systems with highmem, right?  The reason
I propose fixing max_pfn instead of just hacking vpe.c is that, as per my
email of a couple of weeks ago, there are other, architecture independent,
bits of code in the 2.6.24 kernel where max_pfn is assumed to be sane,
and the value of zero may result in otherwise inexplicable Bad Things
happening.  So even if you want to change vpe.c to use max_low_pfn
instead of max_pfn, I believe that we really want that patch to setup.c
until such time as we've verified that the kernel is max_pfn-free.

         Regards,

         Kevin K.

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