From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Baoquan He <bhe@redhat.com>
Cc: hbabus@us.ibm.com, linaro-kernel@lists.linaro.org,
geoff@infradead.org, catalin.marinas@arm.com,
will.deacon@arm.com, linux-kernel@vger.kernel.org,
vgoyal@redhat.com, broonie@kernel.org, david.griego@linaro.org,
kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org
Subject: Re: [v2 1/5] arm64: kdump: reserve memory for crash dump kernel
Date: Tue, 12 May 2015 16:32:39 +0900 [thread overview]
Message-ID: <5551AC97.9040802@linaro.org> (raw)
In-Reply-To: <20150511094115.GB4290@dhcp-128-28.nay.redhat.com>
On 05/11/2015 06:41 PM, Baoquan He wrote:
> On 05/11/15 at 05:17pm, AKASHI Takahiro wrote:
>> On 05/11/2015 04:54 PM, Baoquan He wrote:
>>> In this patch you reserve a separate memory region in 1st kernel to
>>> store elfcorehdr. I am wondering why you don't call add_buffer in
>>> kexec-tools directly. Like this you can get a region from reserved
>>> crashkernel region. Then you don't need reserve_elfcorehdr() to reserve
>>> memory for elfcorehdr specifically. Like other ARCHs do only one memory
>>> region is reserved in 1st kernel, that's crashkernel region.
>>
>> I think that you misunderstand somewhat.
>> * Kexec-tools only locates/identifies a small region for elfcore header within crash kernel's
>> memory region while 1st kernel is running.
>> * the data in elfcore header is filled up by kexec_load system call on 1st kernel.
>> * 1st kernel doesn't reserve any region for elfcore header because the kernel
>> commandline parameters don't contains "elfcorehdr=" parameter, then elfcorehdr_size=0.
>> * Crash dump kernel does reserve the region, as I said, because we don't want to
>> corrupt the info in elfcore header accidentally while crash kernel is running.
>>
>> Clear?
>
> OK, got it now.
>
> Then I am wondering why "elfcorehdr=" can't be contained in kernel
> cmdline as other ARCH does. Maybe I need go over all related threads
> then know why it is. Thanks for explanation.
Kexec-tools on 1st kernel appends "elfcorehdr=" to the kernel command line,
actually chosen/bootargs in a device tree, that is passed to *crash dump kernel*.
So when crash dump kernel boots up, it can recognizes that area (and reserves it
for later use of managing /proc/vmcore.)
Thanks,
-Takahiro AKASHI
> Thanks
> Baoquan
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: takahiro.akashi@linaro.org (AKASHI Takahiro)
To: linux-arm-kernel@lists.infradead.org
Subject: [v2 1/5] arm64: kdump: reserve memory for crash dump kernel
Date: Tue, 12 May 2015 16:32:39 +0900 [thread overview]
Message-ID: <5551AC97.9040802@linaro.org> (raw)
In-Reply-To: <20150511094115.GB4290@dhcp-128-28.nay.redhat.com>
On 05/11/2015 06:41 PM, Baoquan He wrote:
> On 05/11/15 at 05:17pm, AKASHI Takahiro wrote:
>> On 05/11/2015 04:54 PM, Baoquan He wrote:
>>> In this patch you reserve a separate memory region in 1st kernel to
>>> store elfcorehdr. I am wondering why you don't call add_buffer in
>>> kexec-tools directly. Like this you can get a region from reserved
>>> crashkernel region. Then you don't need reserve_elfcorehdr() to reserve
>>> memory for elfcorehdr specifically. Like other ARCHs do only one memory
>>> region is reserved in 1st kernel, that's crashkernel region.
>>
>> I think that you misunderstand somewhat.
>> * Kexec-tools only locates/identifies a small region for elfcore header within crash kernel's
>> memory region while 1st kernel is running.
>> * the data in elfcore header is filled up by kexec_load system call on 1st kernel.
>> * 1st kernel doesn't reserve any region for elfcore header because the kernel
>> commandline parameters don't contains "elfcorehdr=" parameter, then elfcorehdr_size=0.
>> * Crash dump kernel does reserve the region, as I said, because we don't want to
>> corrupt the info in elfcore header accidentally while crash kernel is running.
>>
>> Clear?
>
> OK, got it now.
>
> Then I am wondering why "elfcorehdr=" can't be contained in kernel
> cmdline as other ARCH does. Maybe I need go over all related threads
> then know why it is. Thanks for explanation.
Kexec-tools on 1st kernel appends "elfcorehdr=" to the kernel command line,
actually chosen/bootargs in a device tree, that is passed to *crash dump kernel*.
So when crash dump kernel boots up, it can recognizes that area (and reserves it
for later use of managing /proc/vmcore.)
Thanks,
-Takahiro AKASHI
> Thanks
> Baoquan
>
WARNING: multiple messages have this Message-ID (diff)
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Baoquan He <bhe@redhat.com>
Cc: linux-arm-kernel@lists.infradead.org, hbabus@us.ibm.com,
linaro-kernel@lists.linaro.org, geoff@infradead.org,
catalin.marinas@arm.com, will.deacon@arm.com,
linux-kernel@vger.kernel.org, broonie@kernel.org,
david.griego@linaro.org, kexec@lists.infradead.org,
vgoyal@redhat.com
Subject: Re: [v2 1/5] arm64: kdump: reserve memory for crash dump kernel
Date: Tue, 12 May 2015 16:32:39 +0900 [thread overview]
Message-ID: <5551AC97.9040802@linaro.org> (raw)
In-Reply-To: <20150511094115.GB4290@dhcp-128-28.nay.redhat.com>
On 05/11/2015 06:41 PM, Baoquan He wrote:
> On 05/11/15 at 05:17pm, AKASHI Takahiro wrote:
>> On 05/11/2015 04:54 PM, Baoquan He wrote:
>>> In this patch you reserve a separate memory region in 1st kernel to
>>> store elfcorehdr. I am wondering why you don't call add_buffer in
>>> kexec-tools directly. Like this you can get a region from reserved
>>> crashkernel region. Then you don't need reserve_elfcorehdr() to reserve
>>> memory for elfcorehdr specifically. Like other ARCHs do only one memory
>>> region is reserved in 1st kernel, that's crashkernel region.
>>
>> I think that you misunderstand somewhat.
>> * Kexec-tools only locates/identifies a small region for elfcore header within crash kernel's
>> memory region while 1st kernel is running.
>> * the data in elfcore header is filled up by kexec_load system call on 1st kernel.
>> * 1st kernel doesn't reserve any region for elfcore header because the kernel
>> commandline parameters don't contains "elfcorehdr=" parameter, then elfcorehdr_size=0.
>> * Crash dump kernel does reserve the region, as I said, because we don't want to
>> corrupt the info in elfcore header accidentally while crash kernel is running.
>>
>> Clear?
>
> OK, got it now.
>
> Then I am wondering why "elfcorehdr=" can't be contained in kernel
> cmdline as other ARCH does. Maybe I need go over all related threads
> then know why it is. Thanks for explanation.
Kexec-tools on 1st kernel appends "elfcorehdr=" to the kernel command line,
actually chosen/bootargs in a device tree, that is passed to *crash dump kernel*.
So when crash dump kernel boots up, it can recognizes that area (and reserves it
for later use of managing /proc/vmcore.)
Thanks,
-Takahiro AKASHI
> Thanks
> Baoquan
>
next prev parent reply other threads:[~2015-05-12 7:33 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-24 7:53 [v2 0/5] arm64: add kdump support AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 7:53 ` [v2 1/5] arm64: kdump: reserve memory for crash dump kernel AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 10:11 ` Mark Rutland
2015-04-24 10:11 ` Mark Rutland
2015-04-24 10:11 ` Mark Rutland
2015-05-11 6:44 ` AKASHI Takahiro
2015-05-11 6:44 ` AKASHI Takahiro
2015-05-11 6:44 ` AKASHI Takahiro
2015-04-28 9:19 ` Baoquan He
2015-04-28 9:19 ` Baoquan He
2015-04-28 9:19 ` Baoquan He
2015-05-11 7:38 ` AKASHI Takahiro
2015-05-11 7:38 ` AKASHI Takahiro
2015-05-11 7:38 ` AKASHI Takahiro
2015-05-11 7:54 ` Baoquan He
2015-05-11 7:54 ` Baoquan He
2015-05-11 7:54 ` Baoquan He
2015-05-11 8:17 ` AKASHI Takahiro
2015-05-11 8:17 ` AKASHI Takahiro
2015-05-11 8:17 ` AKASHI Takahiro
2015-05-11 9:41 ` Baoquan He
2015-05-11 9:41 ` Baoquan He
2015-05-11 9:41 ` Baoquan He
2015-05-12 7:32 ` AKASHI Takahiro [this message]
2015-05-12 7:32 ` AKASHI Takahiro
2015-05-12 7:32 ` AKASHI Takahiro
2015-04-24 7:53 ` [v2 2/5] arm64: kdump: implement machine_crash_shutdown() AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 10:39 ` Mark Rutland
2015-04-24 10:39 ` Mark Rutland
2015-04-24 10:39 ` Mark Rutland
2015-04-24 10:43 ` Marc Zyngier
2015-04-24 10:43 ` Marc Zyngier
2015-04-24 10:43 ` Marc Zyngier
2015-08-06 7:09 ` AKASHI Takahiro
2015-08-06 7:09 ` AKASHI Takahiro
2015-08-06 7:09 ` AKASHI Takahiro
2015-08-06 15:51 ` Marc Zyngier
2015-08-06 15:51 ` Marc Zyngier
2015-08-06 15:51 ` Marc Zyngier
2015-08-07 4:24 ` AKASHI Takahiro
2015-08-07 4:24 ` AKASHI Takahiro
2015-08-07 4:24 ` AKASHI Takahiro
2015-05-11 7:10 ` AKASHI Takahiro
2015-05-11 7:10 ` AKASHI Takahiro
2015-05-11 7:10 ` AKASHI Takahiro
2015-05-22 5:56 ` AKASHI Takahiro
2015-05-22 5:56 ` AKASHI Takahiro
2015-05-22 5:56 ` AKASHI Takahiro
2015-04-24 7:53 ` [v2 3/5] arm64: kdump: do not go into EL2 before starting a crash dump kernel AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 7:53 ` [v2 4/5] arm64: add kdump support AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-05-08 12:19 ` Dave Young
2015-05-08 12:19 ` Dave Young
2015-05-08 12:19 ` Dave Young
2015-05-11 7:47 ` Dave Young
2015-05-11 7:47 ` Dave Young
2015-05-11 7:47 ` Dave Young
2015-05-11 7:58 ` AKASHI Takahiro
2015-05-11 7:58 ` AKASHI Takahiro
2015-05-11 7:58 ` AKASHI Takahiro
2015-05-11 8:39 ` Dave Young
2015-05-11 8:39 ` Dave Young
2015-05-11 8:39 ` Dave Young
2015-04-24 7:53 ` [v2 5/5] arm64: enable kdump in the arm64 defconfig AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 7:53 ` AKASHI Takahiro
2015-04-24 9:53 ` [v2 0/5] arm64: add kdump support Mark Rutland
2015-04-24 9:53 ` Mark Rutland
2015-04-24 9:53 ` Mark Rutland
2015-05-11 6:16 ` AKASHI Takahiro
2015-05-11 6:16 ` AKASHI Takahiro
2015-05-11 6:16 ` AKASHI Takahiro
2015-05-12 5:43 ` Dave Young
2015-05-12 5:43 ` Dave Young
2015-05-12 5:43 ` Dave Young
2015-05-18 8:08 ` AKASHI Takahiro
2015-05-18 8:08 ` AKASHI Takahiro
2015-05-18 8:08 ` AKASHI Takahiro
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=5551AC97.9040802@linaro.org \
--to=takahiro.akashi@linaro.org \
--cc=bhe@redhat.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david.griego@linaro.org \
--cc=geoff@infradead.org \
--cc=hbabus@us.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=vgoyal@redhat.com \
--cc=will.deacon@arm.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.