Re: [RFD] efi assisted kdump

[Petr Tesarik <ptesarik@suse.cz>]

On Tue, 27 Jan 2015 14:21:41 +0800
Dave Young <dyoung@redhat.com> wrote:

> Hi, Petr
> 
> On 01/24/15 at 05:03pm, Petr Tesarik wrote:
> > On Sat, 24 Jan 2015 21:26:37 +0800
> > Dave Young <dyoung@redhat.com> wrote:
> > 
> > > Hi,
> > > 
> > > Kdump has several limitations currently such as kdump kernel reboot will bypass
> > > device shutdown path so device drivers should reset during initialization.
> > > 
> > >[...]
> > > 
> > > ppc64 has a feature "firmware assisted kdump", see below documentation:
> > > Documentation/powerpc/firmware-assisted-dump.txt
> > 
> > Hi Dave,
> > 
> > while I'm no expert on either UEFI or IBM POWER, I'd like to warn you
> > that fadump (firmware-assisted dump) on PPC is not quite optimal in its
> > current form. One of the things that have always irritated me are
> > excessive RAM requirements.
> > 
> > The problem is that there is only one reboot in fadump - after saving
> > the dump, the secondary kernel discards the saved area and continues
> > booting as usual. However, many kernel structuers must be already
> > allocated at that point, e.g. the memmap array(s), but they are sized
> > by the total RAM, not the limited amount available to the 2nd kernel.
> 
> Thanks for the comment.
> 
> I'm not sure I understand the RAM requirements you mentioned. I think you
> are worrying about freeing oldmem to be used by 2nd kernel.
> 
> But we do not need to do same as power we can just reboot another time
> as long as vmcore is saved. The main advantage is the capture kernel can
> boot with all devices being reset. 

Yes, that's true. If you're fine with rebooting the machine twice (once
for the dump-taking and once for bringing up the normal system), then
there's no concern. The IBM folks apparently wanted to save some
downtime associated with going through the boot-up sequence. In fact,
you could kexec back into the normal system instead of rebooting, if
kexec can be used.

All I wanted to say is that fadump has its own issues, and we'd better
not repeat them with UEFI-based dumps. ;-)

Petr Tesarik

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec