From: Stephen Warren <swarren@wwwdotorg.org>
To: Vijay Kilari <vijay.kilari@gmail.com>
Cc: "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
"Prasun.Kapoor@caviumnetworks.com"
<Prasun.Kapoor@caviumnetworks.com>,
Will Deacon <will.deacon@arm.com>,
Vijaya Kumar K <Vijaya.Kumar@caviumnetworks.com>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
Date: Tue, 30 Jul 2013 10:59:13 -0600 [thread overview]
Message-ID: <51F7F0E1.5030200@wwwdotorg.org> (raw)
In-Reply-To: <CALicx6ugumPG__rSAsTS95SH=6fTGqhpPFsQ8bLG-u-fbk0=pQ@mail.gmail.com>
On 07/30/2013 04:37 AM, Vijay Kilari wrote:
> On Fri, Jul 26, 2013 at 10:38 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
...
>> Does a kernel that's used as the crash kernel guarantee:
>>
>> * Never to re-use the memory that was used by the previous kernel, so
>> that the spin loop code/data won't be corrupted, ever, no matter how
>> long the crash recovery kernel runs.
>>
>> * Not use SMP, so there's never a need to re-activate the non-boot CPUs,
>> which might not work if they aren't truly disabled but rather just
>> running a pin loop?
>
> From cat /proc/iomem, normal kernel is executed from (0x80xxxxxx) with crash
> kernel reserved 64M@0xa0000000
>
> 80000000-bfffffff : System RAM
> 80008000-805aeddf : Kernel code
> 805e2000-8063e427 : Kernel data
> a0000000-a3ffffff : Crash kernel
>
> crash kernel is loaded to reserved memory location and is executed from there.
> I could confirm this from /proc/iomem when crash kernel is running
>
> a0000000-a3efffff : System RAM
> a0008000-a05aeddf : Kernel code
> a05e2000-a063e427 : Kernel data
OK, but in the crash dump kernel, is 80008000..8063e427 reserved as
well, which would guarantee that the spin loop being executed by the
non-crash CPUs won't be corrupted?
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic
Date: Tue, 30 Jul 2013 10:59:13 -0600 [thread overview]
Message-ID: <51F7F0E1.5030200@wwwdotorg.org> (raw)
In-Reply-To: <CALicx6ugumPG__rSAsTS95SH=6fTGqhpPFsQ8bLG-u-fbk0=pQ@mail.gmail.com>
On 07/30/2013 04:37 AM, Vijay Kilari wrote:
> On Fri, Jul 26, 2013 at 10:38 PM, Stephen Warren <swarren@wwwdotorg.org> wrote:
...
>> Does a kernel that's used as the crash kernel guarantee:
>>
>> * Never to re-use the memory that was used by the previous kernel, so
>> that the spin loop code/data won't be corrupted, ever, no matter how
>> long the crash recovery kernel runs.
>>
>> * Not use SMP, so there's never a need to re-activate the non-boot CPUs,
>> which might not work if they aren't truly disabled but rather just
>> running a pin loop?
>
> From cat /proc/iomem, normal kernel is executed from (0x80xxxxxx) with crash
> kernel reserved 64M at 0xa0000000
>
> 80000000-bfffffff : System RAM
> 80008000-805aeddf : Kernel code
> 805e2000-8063e427 : Kernel data
> a0000000-a3ffffff : Crash kernel
>
> crash kernel is loaded to reserved memory location and is executed from there.
> I could confirm this from /proc/iomem when crash kernel is running
>
> a0000000-a3efffff : System RAM
> a0008000-a05aeddf : Kernel code
> a05e2000-a063e427 : Kernel data
OK, but in the crash dump kernel, is 80008000..8063e427 reserved as
well, which would guarantee that the spin loop being executed by the
non-crash CPUs won't be corrupted?
next prev parent reply other threads:[~2013-07-30 16:59 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-26 5:41 [PATCH] ARM: kexec: offline non panic CPUs on Kdump panic vijay.kilari
2013-07-26 5:41 ` vijay.kilari at gmail.com
2013-07-26 10:49 ` Will Deacon
2013-07-26 10:49 ` Will Deacon
2013-07-26 17:08 ` Stephen Warren
2013-07-26 17:08 ` Stephen Warren
2013-07-26 17:11 ` Will Deacon
2013-07-26 17:11 ` Will Deacon
2013-07-30 10:37 ` Vijay Kilari
2013-07-30 10:37 ` Vijay Kilari
2013-07-30 16:59 ` Stephen Warren [this message]
2013-07-30 16:59 ` Stephen Warren
2013-07-31 11:37 ` Vijay Kilari
2013-07-31 11:37 ` Vijay Kilari
2013-07-31 17:14 ` Stephen Warren
2013-07-31 17:14 ` Stephen Warren
2013-08-01 13:49 ` Vijay Kilari
2013-08-01 13:49 ` Vijay Kilari
2013-08-01 16:25 ` Stephen Warren
2013-08-01 16:25 ` Stephen Warren
2013-08-12 12:18 ` Vijay Kilari
2013-08-12 12:18 ` Vijay Kilari
2013-08-13 11:18 ` Will Deacon
2013-08-13 11:18 ` Will Deacon
2013-07-26 17:05 ` Stephen Warren
2013-07-26 17:05 ` Stephen Warren
2013-07-30 10:05 ` Vijay Kilari
2013-07-30 10:05 ` Vijay Kilari
2013-07-30 16:57 ` Stephen Warren
2013-07-30 16:57 ` Stephen Warren
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=51F7F0E1.5030200@wwwdotorg.org \
--to=swarren@wwwdotorg.org \
--cc=Prasun.Kapoor@caviumnetworks.com \
--cc=Vijaya.Kumar@caviumnetworks.com \
--cc=kexec@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux@arm.linux.org.uk \
--cc=vijay.kilari@gmail.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.