linux-mips
[Top] [All Lists]

Re: Patches for 34K APRP

To: "Kevin D. Kissell" <kevink@mips.com>
Subject: Re: Patches for 34K APRP
From: Ralf Baechle <ralf@linux-mips.org>
Date: Fri, 18 Apr 2008 10:52:52 +0100
Cc: linux-mips@linux-mips.org
In-reply-to: <480752B8.9040601@mips.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <4805FFE6.5080903@mips.com> <20080417124319.GA31453@linux-mips.org> <480752B8.9040601@mips.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.17 (2007-11-01)
On Thu, Apr 17, 2008 at 03:38:00PM +0200, Kevin D. Kissell wrote:

>> 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.

Hmm..  yes.  But your 0002-Propagate-max_low_pfn-as-max_pfn-fo patch
uses max_low_pfn after it has already been cut down to exclude highmem.
Moving the assignment a few lines up just before the if statement should
fix the issue.

  Ralf

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