lkml.org 
[lkml]   [2014]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: kdump failed because of hotplug memory adding in kdump kernel
From
Date
On Fri, 2014-01-10 at 15:11 +0800, Baoquan wrote:
> On 01/09/14 at 02:56pm, Toshi Kani wrote:
:
> > I am more curious to know how makedumpfile decides what memory ranges to
> > dump. The 1st kernel may have performed memory hot-add / delete
> > operations before a crash, so it needs to know the valid physical
> > address range at the time of crash, and may not rely on the E820 map
> > from BIOS (which is stale). Am I right to assume that makedumpfile gets
> > it from the page tables of the 1st kernel?
>
> makedumpfile just do the dump, what memory ranges to dump is decided in
> 1st kernel by kexec-tools. In 1st kernel, if kexec-tools executed, it
> will find all System Ram memorys which exclude the reserved regions for
> kdump kernel, then build a logical elf file, each load segment is one of
> these System Ram memory regions, its addr and length is written into the
> program header.
>
> Then makedumpfile just read this elf file, and read all of them and
> dump.
>
> If after kexec-tools execution and before crash, a hotplug memory is
> removed, udev will check this and trigger a kdump restart, kexec-tools
> is executed again, System Ram region information are stored. The logical
> file header will be passed to 2nd kernel.

Oh, that's how it works. Thanks for the explanation! In case of
hot-delete, ideally, the elf file should be updated after a memory
region is put into off-line, but before it is ejected. But it is
difficult/vulnerable to coordinate such sequence with user space. So,
the current scheme sounds good to me.

Thanks,
-Toshi



\
 
 \ /
  Last update: 2014-01-10 17:21    [W:0.107 / U:0.276 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site