All of lore.kernel.org
 help / color / mirror / Atom feed
From: Don Zickus <dzickus@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Satoru Moriya <satoru.moriya@hds.com>,
	"dle-develop@lists.sourceforge.net"
	<dle-develop@lists.sourceforge.net>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Jarod Wilson <jwilson@redhat.com>,
	Americo Wang <xiyou.wangcong@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Seiji Aguchi <seiji.aguchi@hds.com>,
	Matthew Garrett <mjg@redhat.com>
Subject: Re: [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path
Date: Tue, 19 Jul 2011 15:20:25 -0400	[thread overview]
Message-ID: <20110719192025.GB3400@redhat.com> (raw)
In-Reply-To: <20110719190212.GA4844@redhat.com>

On Tue, Jul 19, 2011 at 03:02:12PM -0400, Vivek Goyal wrote:
> > Another interesting question is do we need to log anything in the kdump
> > path?  Isn't kdump generating the same info?  What added value do we get
> > over kdump?
> 
> I had the same question. The argument is that kdump can fail and they
> can not afford to not capture any info at all. So before kdump executes
> they want to save some state to NVRAM.
> 
> I am wondering that saving this info to NVRAM, can it be done early in
> second kernel? I guess we are not supposed to take any EFI services in
> second kernel so it might not be possible.

Actually the write to NVRAM wouldn't be so bad if ERST supported it.  It
would just be an equvialent to a memcpy.  Currently it uses a complicated
state machine to a persistent storage which complicates things.  As a
result I get nervous if ERST firmware issues would block us from executing
kdump.

Cheers,
Don

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

WARNING: multiple messages have this Message-ID (diff)
From: Don Zickus <dzickus@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Satoru Moriya <satoru.moriya@hds.com>,
	"dle-develop@lists.sourceforge.net"
	<dle-develop@lists.sourceforge.net>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Jarod Wilson <jwilson@redhat.com>,
	Americo Wang <xiyou.wangcong@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Seiji Aguchi <seiji.aguchi@hds.com>,
	Matthew Garrett <mjg@redhat.com>
Subject: Re: [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path
Date: Tue, 19 Jul 2011 15:20:25 -0400	[thread overview]
Message-ID: <20110719192025.GB3400@redhat.com> (raw)
In-Reply-To: <20110719190212.GA4844@redhat.com>

On Tue, Jul 19, 2011 at 03:02:12PM -0400, Vivek Goyal wrote:
> > Another interesting question is do we need to log anything in the kdump
> > path?  Isn't kdump generating the same info?  What added value do we get
> > over kdump?
> 
> I had the same question. The argument is that kdump can fail and they
> can not afford to not capture any info at all. So before kdump executes
> they want to save some state to NVRAM.
> 
> I am wondering that saving this info to NVRAM, can it be done early in
> second kernel? I guess we are not supposed to take any EFI services in
> second kernel so it might not be possible.

Actually the write to NVRAM wouldn't be so bad if ERST supported it.  It
would just be an equvialent to a memcpy.  Currently it uses a complicated
state machine to a persistent storage which complicates things.  As a
result I get nervous if ERST firmware issues would block us from executing
kdump.

Cheers,
Don

WARNING: multiple messages have this Message-ID (diff)
From: Don Zickus <dzickus@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>,
	Matthew Garrett <mjg@redhat.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Americo Wang <xiyou.wangcong@gmail.com>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jarod Wilson <jwilson@redhat.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"dle-develop@lists.sourceforge.net" 
	<dle-develop@lists.sourceforge.net>,
	Satoru Moriya <satoru.moriya@hds.com>
Subject: Re: [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path
Date: Tue, 19 Jul 2011 15:20:25 -0400	[thread overview]
Message-ID: <20110719192025.GB3400@redhat.com> (raw)
In-Reply-To: <20110719190212.GA4844@redhat.com>

On Tue, Jul 19, 2011 at 03:02:12PM -0400, Vivek Goyal wrote:
> > Another interesting question is do we need to log anything in the kdump
> > path?  Isn't kdump generating the same info?  What added value do we get
> > over kdump?
> 
> I had the same question. The argument is that kdump can fail and they
> can not afford to not capture any info at all. So before kdump executes
> they want to save some state to NVRAM.
> 
> I am wondering that saving this info to NVRAM, can it be done early in
> second kernel? I guess we are not supposed to take any EFI services in
> second kernel so it might not be possible.

Actually the write to NVRAM wouldn't be so bad if ERST supported it.  It
would just be an equvialent to a memcpy.  Currently it uses a complicated
state machine to a persistent storage which complicates things.  As a
result I get nervous if ERST firmware issues would block us from executing
kdump.

Cheers,
Don

  reply	other threads:[~2011-07-19 19:20 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-19 18:24 [RFC][PATCH -mmotm 1/4] Add static function calls of pstore to kexec path Seiji Aguchi
2011-07-19 18:24 ` Seiji Aguchi
2011-07-19 18:35 ` Matthew Garrett
2011-07-19 18:35   ` Matthew Garrett
2011-07-19 18:35   ` Matthew Garrett
2011-07-19 18:48   ` Seiji Aguchi
2011-07-19 18:48     ` Seiji Aguchi
2011-07-19 18:48     ` Seiji Aguchi
2011-07-19 18:52     ` Matthew Garrett
2011-07-19 18:52       ` Matthew Garrett
2011-07-19 18:52       ` Matthew Garrett
2011-07-19 19:14       ` Seiji Aguchi
2011-07-19 19:14         ` Seiji Aguchi
2011-07-19 19:14         ` Seiji Aguchi
2011-07-19 19:27         ` Matthew Garrett
2011-07-19 19:27           ` Matthew Garrett
2011-07-19 19:27           ` Matthew Garrett
2011-07-19 19:40           ` Matthew Garrett
2011-07-19 19:40             ` Matthew Garrett
2011-07-19 19:40             ` Matthew Garrett
2011-07-19 18:54     ` Don Zickus
2011-07-19 18:54       ` Don Zickus
2011-07-19 18:54       ` Don Zickus
2011-07-19 19:02       ` Vivek Goyal
2011-07-19 19:02         ` Vivek Goyal
2011-07-19 19:02         ` Vivek Goyal
2011-07-19 19:20         ` Don Zickus [this message]
2011-07-19 19:20           ` Don Zickus
2011-07-19 19:20           ` Don Zickus

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=20110719192025.GB3400@redhat.com \
    --to=dzickus@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dle-develop@lists.sourceforge.net \
    --cc=ebiederm@xmission.com \
    --cc=hpa@zytor.com \
    --cc=jwilson@redhat.com \
    --cc=kexec@lists.infradead.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=mjg@redhat.com \
    --cc=satoru.moriya@hds.com \
    --cc=seiji.aguchi@hds.com \
    --cc=tony.luck@intel.com \
    --cc=vgoyal@redhat.com \
    --cc=xiyou.wangcong@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.