Messages in this thread | | | From | "Chen, Yu C" <> | Subject | RE: [PATCH] [v4] PM / hibernate: Fix hibernation panic caused by inconsistent e820 map | Date | Fri, 18 Sep 2015 06:11:36 +0000 |
| |
Hi, Pavel,
> -----Original Message----- > From: Pavel Machek [mailto:pavel@ucw.cz] > Sent: Friday, September 18, 2015 1:47 PM > To: Chen, Yu C > Cc: rjw@rjwysocki.net; Brown, Len; linux-pm@vger.kernel.org; linux- > kernel@vger.kernel.org; Zhang, Rui; jlee@suse.com; > joeyli.kernel@gmail.com; yinghai@kernel.org; Ingo Molnar > Subject: Re: [PATCH] [v4] PM / hibernate: Fix hibernation panic caused by > inconsistent e820 map > > > > 3) I'm not sure I understand the changelog correctly. What happens > > > when BIOS reports less memory on hibernation? Will you magically > > > remove memory from kernel at runtime? Will /proc/meminfo be invalid > after resume? > > > Will all the memory management tuning need fixing? > > > > > Oh, I did not notice it before. So deleting the logic of ' > > info->num_physpages != get_num_physpages()' is not suitable. > > The subset relationship should not be considered in this patch. > > Ok. So... if you really want, you can add some messages like "hey, this is bios > bug, maybe updating bios is a good idea".. but please lets keep the original > logic. > OK. I see, I'll not change its original code. So can I add a function here that checks if current BIOS e820 map is strictly the same as it was before S4? If it is not the same, we will print some warnnings , and if we panic later, we will print that , the panic reason might be due to broken BIOS. I think I can archive this by putting the e820_saved array into struct swsusp_info, and pass it to second kernel: struct swsusp_info will always occupy one page size, and has a lot of extra space left, meanwhile the total size of e820 map will not exceed the PAGE_SIZE currently, it's safe to put it in struct swsusp_info.
And this does not need much changing of current code. What do you think? Thanks.
Best Regards, Yu
| |