From: Dave Young <dyoung-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org
Subject: Re: [RFD] efi assisted kdump
Date: Tue, 27 Jan 2015 14:24:34 +0800 [thread overview]
Message-ID: <20150127062433.GD2506@darkstar.redhat.com> (raw)
In-Reply-To: <20150126140843.GA25559-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 01/26/15 at 09:08am, Vivek Goyal wrote:
> On Sat, Jan 24, 2015 at 09:26:37PM +0800, Dave Young wrote:
> > Hi,
> >
> > Kdump has several limitations currently such as kdump kernel reboot will bypass
> > device shutdown path so device drivers should reset during initialization.
> >
> > * One of such problem we encounter now is the iommu
> > issue, 1st kernel's on fly DMA requests cause 2nd kernel hang. There's some effort
> > on this area, Zhenhua Li posted patches to resolve the intel iommu issue which is
> > under review. But that is just one case there's other possible problems in the future.
> >
> > * There's no serial console on most machines in the market especially for desktop
> > machines and laptops. kms enabled kernel need drm layer driver for framebuffer
> > console, after kernel crashing we need a console to see the 2nd kernel output
> > ideally a serial console because we can not switch back to VGA mode.
> >
> > ppc64 has a feature "firmware assisted kdump", see below documentation:
> > Documentation/powerpc/firmware-assisted-dump.txt
> >
> > In case UEFI machines I wonder if we can do similar things, basic idea is doing
> > minimum thing based on original kdump process.
> >
> > kernel reserve crashkernel memory during early boot
> > -> user (kdump service) save necessary informations in some way so that second
> > kernel boot can access ie. efi runtime variables or in reserved memory
> > * crashkernel memory ranges infomation
> > * collect infomations and save elf notes for 2nd kernel vmcore initialization
>
> I think anything related to vmcore initilization can be in memory
> somewhere and should not be a problem.
>
> But we do have to think about anything which is passed in bootparams or
> command line to second kenrnel with current mechanism, how will it be
> passed to second kernel.
Hi, Vivek,
Since we are rebooting via efi maybe we can just choose another boot entry
in grub.cfg with the proper cmdline?
Thanks
Dave
next prev parent reply other threads:[~2015-01-27 6:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-24 13:26 [RFD] efi assisted kdump Dave Young
[not found] ` <20150124132637.GB2139-4/PLUo9XfK/1wF9wiOj0lkEOCMrvLtNR@public.gmane.org>
2015-01-26 14:08 ` Vivek Goyal
[not found] ` <20150126140843.GA25559-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-01-27 6:24 ` Dave Young [this message]
2015-01-26 16:39 ` Matt Fleming
[not found] ` <20150126163941.GD3320-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
2015-01-27 6:37 ` Dave Young
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=20150127062433.GD2506@darkstar.redhat.com \
--to=dyoung-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=kexec-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox