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

["Rafael J. Wysocki" <rjw@sisk.pl>]

On Thursday, September 22, 2011, Yinghai Lu wrote:
> On Wed, Sep 21, 2011 at 11:48 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > It looks like init_memory_mapping() is sometimes called with "end"
> > beyond the last mapped PFN and it explodes when we try to write stuff to
> > that address during image restoration.
> >
> > IOW, the Yinghai's assumption that init_memory_mapping() would always be
> > called with a "good end" on x86_64 was overomptimistic.
> 
> for 64bit x86, kernel_physical_mapping_init() will use
> map_low_page()/call early_memmap() to access ram for page_table that is above
> rather last mapped PFN.
> 
> the point is:
> on system with 64g, usable ram will be [0,2048m), [4g, 64g)
> init_memory_mapping will be called two times for them.
> before putting page_table high,
> page table will be two parts: one is just below 512M, and one below 2048m.
> after putting page_table high,
> page table will be two parts: one is just below 2048M, and one below 64G.
> 
> one of the purposes is finding biggest continuous big range under
> 1024m for kdump.

This is all fine so long as we can ensure that the "end" value we're
passing to init_memory_mapping() will always be a valid address, which
evidently is not the case sometimes.

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.

Thanks,
Rafael