>Currently, there is no obvious description in IMPLEMENTATION for >distinguishing the lost pages resulted by ENOSPACE errors or others. >So, it is added. Thanks for re-posting, I'll merge this into v1.5.9. Regards, Atsushi Kumagai >Signed-off-by: Zhou Wenjian <zhouwj-fnst at cn.fujitsu.com> >--- > IMPLEMENTATION | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > >diff --git a/IMPLEMENTATION b/IMPLEMENTATION >index 72df5d5..589c5bf 100644 >--- a/IMPLEMENTATION >+++ b/IMPLEMENTATION >@@ -240,6 +240,10 @@ > The page header and page data are written in pairs. When writing page data > (pfn N+1), if ENOSPACE error happens, the page headers after N won't be > written either. >+ Since the data lost is filled with zero when it is read, the page_desc->offset >+ will also be zero. And zero page has its own offset not equal 0. So when reading >+ page from incomplete core, only the page lost by ENOSPACE errors has 0 in its >+ corresponding page descriptor's member offset. > > If there is no page data dumped into the DUMPFILE, the DUMPFILE can't be > analysed by crash. >-- >1.7.1 > > >_______________________________________________ >kexec mailing list >kexec at lists.infradead.org >http://lists.infradead.org/mailman/listinfo/kexec
