From: Pavel Machek <pavel@ucw.cz>
To: Chen Yu <yu.c.chen@intel.com>
Cc: rjw@rjwysocki.net, len.brown@intel.com, mingo@redhat.com,
yinghai@kernel.org, joeyli.kernel@gmail.com,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] [v2] PM / hibernate: Fix hibernation panic caused by inconsistent e820 map
Date: Thu, 17 Sep 2015 07:40:27 +0200 [thread overview]
Message-ID: <20150917054027.GC6665@amd> (raw)
In-Reply-To: <1441101816-24567-1-git-send-email-yu.c.chen@intel.com>
Hi!
> PM: Image mismatch: memory size
>
> This is also because BIOS provides different e820 memory map before/after
> hibernation, and linux regards it as invalid process and refuses to
> resume, in order to protect against data corruption. However,
> this check might be too strict, consider the following scenario:
Well... yes, the check is strict, but why is BIOS doing that? Can you
fix it instead?
> The hibernating system has a smaller memory capacity than
> the resuming system, and the former memory region is a subset of the
> latter, it should be allowed to resume. Here is a case for this
> situation:
>
> before hibernation:
>
> BIOS-e820: [mem 0x0000000020200000-0x0000000077517fff] usable
> BIOS-e820: [mem 0x0000000077518000-0x0000000077567fff] reserved
> Memory: 3871356K/4058428K available (7595K kernel code, 1202K rwdata,
> 3492K rodata, 1400K init, 1308K bss, 187072K reserved, 0K cma-reserved)
>
> after hibernation:
> BIOS-e820: [mem 0x0000000020200000-0x000000007753ffff] usable
> BIOS-e820: [mem 0x0000000077540000-0x0000000077567fff] reserved
> Memory: 3871516K/4058588K available (7595K kernel code, 1202K rwdata,
> 3492K rodata, 1400K init, 1308K bss, 187072K reserved, 0K cma-reserved)
>
> According to above data, the number of present_pages has increased by
> 40(thus 160K), linux will terminate the resuming process. But since
> [0x0000000020200000-0x0000000077517fff] is a subset of
> [0x0000000020200000-0x000000007753ffff], we should let system
> resume.
Ok, complex, but will work. But what happens in the opposite case? On
the next boot, bios gets you 160K less....
Can you do echo powerdown > /sys/power/disk to work around this?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
prev parent reply other threads:[~2015-09-17 5:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-01 10:03 [PATCH] [v2] PM / hibernate: Fix hibernation panic caused by inconsistent e820 map Chen Yu
2015-09-02 8:24 ` Chen, Yu C
2015-09-17 5:40 ` Pavel Machek [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150917054027.GC6665@amd \
--to=pavel@ucw.cz \
--cc=joeyli.kernel@gmail.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=yinghai@kernel.org \
--cc=yu.c.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.