Re: S4 resume broken since 2.6.39 (3.1, too)

[Yinghai Lu <yinghai.lu@oracle.com>]

On 09/26/2011 03:47 PM, Linus Torvalds wrote:

> On Mon, Sep 26, 2011 at 3:24 PM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>>
>> So, in my opinion we should simply apply the Takashi's patch at this
>> point and revisit the kdump issue later, when we actually know how to do
>> the right thing.
> 
> Applying that trivial patch certainly looks fine, especially since it
> also avoids some arbitrary differences between x86-64 and x86-32.
> 
> That said, the whole code looks *very* confusing, and I have to say
> that the commit logs there are also totally unreadable and not very
> explanatory at all.


sorry for that.

> 
> It does seem like the code is simply buggy: it "allocates" the page
> tables from the end of memory, but it seems to want to do that before
> they have been mapped. Which makes perfect sense, since the whole
> point of allocating them is to be *able* to map all the memory.

> 

> So using that
> 
>     good_end = max_pfn_mapped << PAGE_SHIFT;
> 
> would seem to be a good idea regardless. I'm not sure how the old code
> is even supposed to work. That said - why is this a problem only for
> S4 resume?


and for S4 resume, according to Takashi, that commit is ok with 2.6.37. but start to have some problem (1/20 chance) from 2.6.39...

will check if any other early page-table related commit could cause the problem.

the main point for that commit: it will "allocate" range for page-table purpose and will use early_memremap before really accessing them.
so could have the end above already mapped max address.

so We can avoid to put page_table in the middle of low ram ( just below 512m ), and could have bigger continuous range for kdump kernel.

Thanks

Yinghai