Re: 2.6.38.2 breaks suspend to disk

[Yinghai Lu <yinghai@kernel.org>]

On 04/01/2011 09:22 AM, H. Peter Anvin wrote:
> On 04/01/2011 09:06 AM, Yinghai Lu wrote:
>> Index: linux-2.6/arch/x86/kernel/setup.c
>> ===================================================================
>> --- linux-2.6.orig/arch/x86/kernel/setup.c
>> +++ linux-2.6/arch/x86/kernel/setup.c
>> @@ -294,10 +294,17 @@ static void __init init_gbpages(void)
>>       else
>>           direct_gbpages = 0;
>>   }
>> +static void __init store_mmu_cr4(void)
>> +{
>> +    mmu_cr4_features = read_cr4();
>> +}
>>   #else
>>   static inline void init_gbpages(void)
>>   {
>>   }
>> +static void __init store_mmu_cr4(void)
>> +{
>> +}
>>   static void __init cleanup_highmap(void)
>>   {
>>   }
>> @@ -929,6 +936,8 @@ void __init setup_arch(char **cmdline_p)
>>       /* max_pfn_mapped is updated here */
>>       max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn<<PAGE_SHIFT);
>>       max_pfn_mapped = max_low_pfn_mapped;
>> +    /* after init_memory_mapping updating cr4*/
>> +    store_mmu_cr4();
>>
>>   #ifdef CONFIG_X86_64
>>       if (max_pfn>  max_low_pfn) {
>
> This looks really, really, really wrong.
>
> Why the heck should we save and restore CR4 only for x86-64?

Peter, this patch just restoring old sequence. If you think 32 bit should do same thing, we can do that in another patch.

Also after closing looking, Stefano's v1 patch should be ok too.
because init_memory_mapping is using set_in_cr4(...) and it will update mmu_cr4_features at the same time.

Thanks

Yinghai