Re: Patches for 34K APRP

["Kevin D. Kissell" <kevink@mips.com>]

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.