From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: jerry.hoemann@hp.com
Cc: fengguang.wu@intel.com, jingbai.ma@hp.com,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
bp@alien8.de, ebiederm@xmission.com, akpm@linux-foundation.org,
hpa@linux.intel.com, vgoyal@redhat.com
Subject: Re: [PATCH v4 0/3] x86, apic, kexec: Add disable_cpu_apic kernel parameter
Date: Thu, 31 Oct 2013 13:43:24 +0900 [thread overview]
Message-ID: <5271DFEC.7070802@jp.fujitsu.com> (raw)
In-Reply-To: <20131031005812.GA15459@anatevka.fc.hp.com>
(2013/10/31 9:58), jerry.hoemann@hp.com wrote:
> On Wed, Oct 23, 2013 at 09:05:06AM +0900, HATAYAMA Daisuke wrote:
>>>>
>>>> - Rebased on top of v3.12-rc6
>>>>
>>>> - Basic design has been changed. Now users need to figure out initial
>>>> APIC ID of BSP in the 1st kernel and configures kernel parameter for
>>>> the 2nd kernel manually using disable_cpu_apic kernel parameter to
>>>> be newly introduced in this patch set. This design is more flexible
>>>> than the previous version in that we no longer have to rely on
>>>> ACPI/MP table to get initial APIC ID of BSP.
>>>
>>>
>>> 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.
>>
>> HATAYAMA, Daisuke
>
>
> Daisuke,
>
> Are you planning on making changes to the kexec tools to automate
> the setting of disable_cpu_apic to the capture kernel? Or do you
> know someone who is planning this?
>
> I back ported the kernel side changes to a 4.2.32 based kernel.
> I tested the patch on a prototype system which exhibits a stable
> initial_apic_id for CPU 0. While not something that would be suitable
> for customers, it does allow me to test the kernel portion of the patch.
>
> I will report the results of the testing later this week.
>
I'll do that after this patch is merged in kernel. But it is still under
reviewing.
--
Thanks.
HATAYAMA, Daisuke
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>
To: jerry.hoemann@hp.com
Cc: hpa@linux.intel.com, ebiederm@xmission.com, vgoyal@redhat.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: Thu, 31 Oct 2013 13:43:24 +0900 [thread overview]
Message-ID: <5271DFEC.7070802@jp.fujitsu.com> (raw)
In-Reply-To: <20131031005812.GA15459@anatevka.fc.hp.com>
(2013/10/31 9:58), jerry.hoemann@hp.com wrote:
> On Wed, Oct 23, 2013 at 09:05:06AM +0900, HATAYAMA Daisuke wrote:
>>>>
>>>> - Rebased on top of v3.12-rc6
>>>>
>>>> - Basic design has been changed. Now users need to figure out initial
>>>> APIC ID of BSP in the 1st kernel and configures kernel parameter for
>>>> the 2nd kernel manually using disable_cpu_apic kernel parameter to
>>>> be newly introduced in this patch set. This design is more flexible
>>>> than the previous version in that we no longer have to rely on
>>>> ACPI/MP table to get initial APIC ID of BSP.
>>>
>>>
>>> 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.
>>
>> HATAYAMA, Daisuke
>
>
> Daisuke,
>
> Are you planning on making changes to the kexec tools to automate
> the setting of disable_cpu_apic to the capture kernel? Or do you
> know someone who is planning this?
>
> I back ported the kernel side changes to a 4.2.32 based kernel.
> I tested the patch on a prototype system which exhibits a stable
> initial_apic_id for CPU 0. While not something that would be suitable
> for customers, it does allow me to test the kernel portion of the patch.
>
> I will report the results of the testing later this week.
>
I'll do that after this patch is merged in kernel. But it is still under
reviewing.
--
Thanks.
HATAYAMA, Daisuke
next prev parent reply other threads:[~2013-10-31 4:46 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
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 [this message]
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=5271DFEC.7070802@jp.fujitsu.com \
--to=d.hatayama@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--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 \
--cc=vgoyal@redhat.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.