All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: fengguang.wu@intel.com, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, jerry.hoemann@hp.com, bp@alien8.de,
	ebiederm@xmission.com, akpm@linux-foundation.org,
	hpa@linux.intel.com, jingbai.ma@hp.com
Subject: Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter
Date: Wed, 23 Oct 2013 11:51:27 -0400	[thread overview]
Message-ID: <20131023155127.GA17437@redhat.com> (raw)
In-Reply-To: <526712B2.7070108@jp.fujitsu.com>

On Wed, Oct 23, 2013 at 09:05:06AM +0900, HATAYAMA Daisuke wrote:

[..]
> >Do you literally mean a human at each boot will have to configure
> >the kdump configuration files for passing disable_cpu_apic?
> >Or do you envision the setting of disable_cpu_apic being put into
> >the kdump initialization scripts?
> >
> >thanks
> >
> >Jerry
> 
> Nearer to the former case, but this is not what a human should do. It's
> a cumbersome task. I think, on fedora/RHEL system for example, kdump
> service should check at each boot automatically.

Hi Hatayama,

So what information should I look for to prepare disable_cpu_apic=X in
kdump script?

Is BSP processor info exported to user space somewhere? Or assuming that
processor 0 is BSP and corresponding apicid should be disabled in kdump
kernel is good enough?

I am looking at /proc/cpuinfo and following 3 fields seem interesting.

processor: 0
apicid		: 0
initial apicid	: 0

What's the difference between apicid and "initial apicid". I guess
initial apicid reflects the apicid number as set by firmware and then
kernel can overwrite it and new number would be reflected in "apicid"?

If that's the case, then I guess we should be looking at "apicid" of
processor "0" and set that in disable_cpu_apic? Because that's the
number kdump kernel  boot should see in apic upon boot.

Thanks
Vivek

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

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
Cc: jerry.hoemann@hp.com, hpa@linux.intel.com, ebiederm@xmission.com,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	bp@alien8.de, akpm@linux-foundation.org, fengguang.wu@intel.com,
	jingbai.ma@hp.com
Subject: Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter
Date: Wed, 23 Oct 2013 11:51:27 -0400	[thread overview]
Message-ID: <20131023155127.GA17437@redhat.com> (raw)
In-Reply-To: <526712B2.7070108@jp.fujitsu.com>

On Wed, Oct 23, 2013 at 09:05:06AM +0900, HATAYAMA Daisuke wrote:

[..]
> >Do you literally mean a human at each boot will have to configure
> >the kdump configuration files for passing disable_cpu_apic?
> >Or do you envision the setting of disable_cpu_apic being put into
> >the kdump initialization scripts?
> >
> >thanks
> >
> >Jerry
> 
> Nearer to the former case, but this is not what a human should do. It's
> a cumbersome task. I think, on fedora/RHEL system for example, kdump
> service should check at each boot automatically.

Hi Hatayama,

So what information should I look for to prepare disable_cpu_apic=X in
kdump script?

Is BSP processor info exported to user space somewhere? Or assuming that
processor 0 is BSP and corresponding apicid should be disabled in kdump
kernel is good enough?

I am looking at /proc/cpuinfo and following 3 fields seem interesting.

processor: 0
apicid		: 0
initial apicid	: 0

What's the difference between apicid and "initial apicid". I guess
initial apicid reflects the apicid number as set by firmware and then
kernel can overwrite it and new number would be reflected in "apicid"?

If that's the case, then I guess we should be looking at "apicid" of
processor "0" and set that in disable_cpu_apic? Because that's the
number kdump kernel  boot should see in apic upon boot.

Thanks
Vivek

  reply	other threads:[~2013-10-23 15:53 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-22 15:01 [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter HATAYAMA Daisuke
2013-10-22 15:01 ` HATAYAMA Daisuke
2013-10-22 15:01 ` [PATCH v4 1/3] x86, apic: Don't count the CPU with BP flag from MP table as booting-up CPU HATAYAMA Daisuke
2013-10-22 15:01   ` HATAYAMA Daisuke
2013-11-08 16:08   ` Vivek Goyal
2013-11-08 16:08     ` Vivek Goyal
2013-11-11  2:52     ` HATAYAMA Daisuke
2013-11-11  2:52       ` HATAYAMA Daisuke
2013-11-11 16:52       ` Vivek Goyal
2013-11-11 16:52         ` Vivek Goyal
2013-11-12  0:40         ` HATAYAMA Daisuke
2013-11-12  0:40           ` HATAYAMA Daisuke
2013-11-12  9:58           ` HATAYAMA Daisuke
2013-11-12  9:58             ` HATAYAMA Daisuke
2013-10-22 15:01 ` [PATCH v4 2/3] x86, apic: Add disable_cpu_apicid kernel parameter HATAYAMA Daisuke
2013-10-22 15:01   ` HATAYAMA Daisuke
2013-10-22 15:01 ` [PATCH v4 3/3] Documentation, x86, apic, kexec: " HATAYAMA Daisuke
2013-10-22 15:01   ` HATAYAMA Daisuke
2013-10-22 22:08 ` [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic " jerry.hoemann
2013-10-23  0:05   ` HATAYAMA Daisuke
2013-10-23  0:05     ` HATAYAMA Daisuke
2013-10-23 15:51     ` Vivek Goyal [this message]
2013-10-23 15:51       ` Vivek Goyal
2013-10-24  1:42       ` HATAYAMA Daisuke
2013-10-24  1:42         ` HATAYAMA Daisuke
2013-10-25 11:05         ` Petr Tesarik
2013-10-29  0:53           ` HATAYAMA Daisuke
2013-10-29  7:39             ` Petr Tesarik
2013-10-24  5:50       ` Eric W. Biederman
2013-10-24  5:50         ` Eric W. Biederman
2013-10-31  0:58     ` jerry.hoemann
2013-10-31  4:43       ` HATAYAMA Daisuke
2013-10-31  4:43         ` HATAYAMA Daisuke
2013-10-31 13:27       ` Vivek Goyal
2013-10-31 13:27         ` Vivek Goyal
2013-11-01  0:31         ` Simon Horman
2013-11-01  0:31           ` Simon Horman
2013-11-01  7:54         ` jerry.hoemann
2013-11-04  7:08         ` HATAYAMA Daisuke
2013-11-04  7:08           ` HATAYAMA Daisuke
2013-10-29 14:21 ` Baoquan He
2013-10-29 14:21   ` Baoquan He
2013-10-30  0:44   ` HATAYAMA Daisuke
2013-10-30  0:44     ` HATAYAMA Daisuke
2013-10-30  6:06     ` Baoquan He
2013-10-30  6:06       ` Baoquan He
2013-10-30  9:48       ` HATAYAMA Daisuke
2013-10-30  9:48         ` HATAYAMA Daisuke
2013-10-30 15:27   ` Baoquan He
2013-10-30 15:27     ` Baoquan He
2013-11-06 19:02 ` jerry.hoemann
2013-11-11  4:49   ` HATAYAMA Daisuke
2013-11-11  4:49     ` HATAYAMA Daisuke
2013-11-13 18:27     ` jerry.hoemann
2013-11-08  3:30 ` Baoquan He
2013-11-08  3:30   ` Baoquan He
2013-11-08  4:13   ` HATAYAMA Daisuke
2013-11-08  4:13     ` HATAYAMA Daisuke

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=20131023155127.GA17437@redhat.com \
    --to=vgoyal@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=ebiederm@xmission.com \
    --cc=fengguang.wu@intel.com \
    --cc=hpa@linux.intel.com \
    --cc=jerry.hoemann@hp.com \
    --cc=jingbai.ma@hp.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.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.