[Top] [All Lists]

Re: Patches for 34K APRP

To: "Kevin D. Kissell" <>
Subject: Re: Patches for 34K APRP
From: Ralf Baechle <>
Date: Fri, 18 Apr 2008 10:52:52 +0100
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <>
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.


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