All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: len.brown@intel.com, fenghua.yu@intel.com, x86@kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	rob.herring@calxeda.com, grant.likely@secretlab.ca,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	ebiederm@xmission.com, hpa@zytor.com, tglx@linutronix.de,
	mingo@elte.hu
Subject: Re: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP
Date: Mon, 22 Oct 2012 19:10:15 +0200	[thread overview]
Message-ID: <20121022191015.2989b7a0@holzheu> (raw)
In-Reply-To: <20121019151753.GF27052@redhat.com>

On Fri, 19 Oct 2012 11:17:53 -0400
Vivek Goyal <vgoyal@redhat.com> wrote:

[..]

> On Fri, Oct 19, 2012 at 12:20:54PM +0900, HATAYAMA Daisuke wrote:
> I am skeptical that this approach is going to fly in practice. Dumping
> huge images, processing and transferring these is not very practical.
> So I would rather narrow down the problem on a running system and take
> filtered dump of appropriate component where I suspect the problem is.
> 
> [..]
> > > capability was the primary reason that s390 also wants to support
> > > kdump otherwise there firmware dumping mechanism was working just
> > > fine.
> > > 
> > 
> > I don't know s390 firmware dumping mechanism at all, but is it
> > possble for s390 to filter crash dump even on firmware dumping
> > mechanism?
> 
> AFAIK, s390 dump mechanism could not filter dump and tha's the reason
> they wanted to support kdump and /proc/vmcore so that makedumpfile 
> could filter it. I am CCing Michael Holzheu, who did the s390 kdump
> work. He can tell it better.

Correct. The other s390 dump mechanisms (stand-alone and hypervisor
dump) are not able to do filtering and therefore the handling of large
dumps has been a problem for us.

This was one of the main reasons to implement kdump on s390.

Michael


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

WARNING: multiple messages have this Message-ID (diff)
From: Michael Holzheu <holzheu@linux.vnet.ibm.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	x86@kernel.org, mingo@elte.hu, tglx@linutronix.de, hpa@zytor.com,
	len.brown@intel.com, fenghua.yu@intel.com, ebiederm@xmission.com,
	grant.likely@secretlab.ca, rob.herring@calxeda.com
Subject: Re: [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP
Date: Mon, 22 Oct 2012 19:10:15 +0200	[thread overview]
Message-ID: <20121022191015.2989b7a0@holzheu> (raw)
In-Reply-To: <20121019151753.GF27052@redhat.com>

On Fri, 19 Oct 2012 11:17:53 -0400
Vivek Goyal <vgoyal@redhat.com> wrote:

[..]

> On Fri, Oct 19, 2012 at 12:20:54PM +0900, HATAYAMA Daisuke wrote:
> I am skeptical that this approach is going to fly in practice. Dumping
> huge images, processing and transferring these is not very practical.
> So I would rather narrow down the problem on a running system and take
> filtered dump of appropriate component where I suspect the problem is.
> 
> [..]
> > > capability was the primary reason that s390 also wants to support
> > > kdump otherwise there firmware dumping mechanism was working just
> > > fine.
> > > 
> > 
> > I don't know s390 firmware dumping mechanism at all, but is it
> > possble for s390 to filter crash dump even on firmware dumping
> > mechanism?
> 
> AFAIK, s390 dump mechanism could not filter dump and tha's the reason
> they wanted to support kdump and /proc/vmcore so that makedumpfile 
> could filter it. I am CCing Michael Holzheu, who did the s390 kdump
> work. He can tell it better.

Correct. The other s390 dump mechanisms (stand-alone and hypervisor
dump) are not able to do filtering and therefore the handling of large
dumps has been a problem for us.

This was one of the main reasons to implement kdump on s390.

Michael


  parent reply	other threads:[~2012-10-22 17:10 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-16  4:35 [PATCH v1 0/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke
2012-10-16  4:35 ` HATAYAMA Daisuke
2012-10-16  4:35 ` [PATCH v1 1/2] x86, apic: Introduce boot_cpu_is_bsp indicating whether boot cpu is BSP or not HATAYAMA Daisuke
2012-10-16  4:35   ` HATAYAMA Daisuke
2012-10-16  4:35 ` [PATCH v1 2/2] x86, apic: Disable BSP if boot cpu is AP HATAYAMA Daisuke
2012-10-16  4:35   ` HATAYAMA Daisuke
2012-10-22 20:04   ` Eric W. Biederman
2012-10-22 20:04     ` Eric W. Biederman
2012-10-22 20:16     ` H. Peter Anvin
2012-10-22 20:16       ` H. Peter Anvin
2012-10-22 20:31       ` Eric W. Biederman
2012-10-22 20:31         ` Eric W. Biederman
2012-10-22 20:33         ` H. Peter Anvin
2012-10-22 20:33           ` H. Peter Anvin
2012-10-22 20:38           ` H. Peter Anvin
2012-10-22 20:38             ` H. Peter Anvin
2012-10-22 20:43           ` Eric W. Biederman
2012-10-22 20:43             ` Eric W. Biederman
2012-10-22 20:47             ` H. Peter Anvin
2012-10-22 20:47               ` H. Peter Anvin
2012-10-22 21:29               ` Eric W. Biederman
2012-10-22 21:29                 ` Eric W. Biederman
2012-10-23  0:35                 ` H. Peter Anvin
2012-10-23  0:35                   ` H. Peter Anvin
2012-10-26  3:24                   ` HATAYAMA Daisuke
2012-10-26  3:24                     ` HATAYAMA Daisuke
2012-10-26  4:13                     ` Eric W. Biederman
2012-10-26  4:13                       ` Eric W. Biederman
2013-03-11  1:07                       ` HATAYAMA Daisuke
2013-03-11  1:07                         ` HATAYAMA Daisuke
2013-03-11  2:13                         ` HATAYAMA Daisuke
2013-03-11  2:13                           ` HATAYAMA Daisuke
2013-03-11  4:11                           ` H. Peter Anvin
2013-03-11  4:11                             ` H. Peter Anvin
2012-10-16  4:51 ` [PATCH v1 0/2] " Yu, Fenghua
2012-10-16  4:51   ` Yu, Fenghua
2012-10-16  5:03   ` HATAYAMA Daisuke
2012-10-16  5:03     ` HATAYAMA Daisuke
2012-10-16  5:14     ` Yu, Fenghua
2012-10-16  5:14       ` Yu, Fenghua
2012-10-16  6:38       ` HATAYAMA Daisuke
2012-10-16  6:38         ` HATAYAMA Daisuke
2012-10-22 16:02         ` H. Peter Anvin
2012-10-22 16:02           ` H. Peter Anvin
2012-10-16  5:15     ` HATAYAMA Daisuke
2012-10-16  5:15       ` HATAYAMA Daisuke
2012-10-17 14:12 ` Vivek Goyal
2012-10-17 14:12   ` Vivek Goyal
2012-10-18  3:08   ` HATAYAMA Daisuke
2012-10-18  3:08     ` HATAYAMA Daisuke
2012-10-18 14:14     ` Vivek Goyal
2012-10-18 14:14       ` Vivek Goyal
2012-10-19  3:20       ` HATAYAMA Daisuke
2012-10-19  3:20         ` HATAYAMA Daisuke
2012-10-19 15:17         ` Vivek Goyal
2012-10-19 15:17           ` Vivek Goyal
2012-10-22  6:32           ` HATAYAMA Daisuke
2012-10-22  6:32             ` HATAYAMA Daisuke
2012-10-22 18:37             ` Vivek Goyal
2012-10-22 18:37               ` Vivek Goyal
2012-10-22 17:10           ` Michael Holzheu [this message]
2012-10-22 17:10             ` Michael Holzheu

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=20121022191015.2989b7a0@holzheu \
    --to=holzheu@linux.vnet.ibm.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=ebiederm@xmission.com \
    --cc=fenghua.yu@intel.com \
    --cc=grant.likely@secretlab.ca \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rob.herring@calxeda.com \
    --cc=tglx@linutronix.de \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.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 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.