Re: Patches for 34K APRP

[Ralf Baechle <ralf@linux-mips.org>]

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