All of lore.kernel.org
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Simon Horman <horms@verge.net.au>
Cc: geoff@infradead.org, panand@redhat.com, kexec@lists.infradead.org
Subject: Re: [PATCH v3 0/8] (kexec-tools) arm64: add kdump support
Date: Thu, 29 Sep 2016 07:26:48 -0700	[thread overview]
Message-ID: <20160929142646.GB5218@localhost> (raw)
In-Reply-To: <20160929083909.GI14497@verge.net.au>

Simon,

On Thu, Sep 29, 2016 at 10:39:09AM +0200, Simon Horman wrote:
> On Thu, Sep 29, 2016 at 01:18:06AM -0700, AKASHI Takahiro wrote:
> > On Thu, Sep 29, 2016 at 09:52:00AM +0200, Simon Horman wrote:
> > > On Wed, Sep 07, 2016 at 01:33:53PM +0900, AKASHI Takahiro wrote:
> > > > My kernel patches of kdump suport on arm64 are currently under reviews.
> > > > 
> > > > This patchset is synced with them (v26 [1]) and provides necessary changes
> > > > for kexec-tools. It should be applied on top of Geoff's kexec-tools patches
> > > > v5[2] along with a bugfix[3].
> > > > 
> > > > [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-September/454588.html
> > > > [2] http://lists.infradead.org/pipermail/kexec/2016-September/017110.html
> > > > [3] http://lists.infradead.org/pipermail/kexec/2016-July/016664.html
> > > 
> > > Unfortunately patch 2 does not seem to apply cleanly any more.
> > > Could you consider rebasing if you think this series is ready to be
> > > applied?
> > 
> > Yes, I will as there will be some changes needed again due to the discussions
> > on my kernel patch.
> > 
> > BTW, can you give me your opinion on my question, please?
> > 
> > http://lists.infradead.org/pipermail/kexec/2016-September/017119.html
> 
> I'm not particularly familiar with UEFI systems but for DT something under
> chosen seems to make sense.
> 
> Regarding Mark's objections to a memmap= command line parameter.
> Perhaps that could be discussed further in the context that even
> though it is not particularly attractive it it being used on other
> architecture(s).


Oops, my question was not accurate here.
Instead, see the discussions:
http://lists.infradead.org/pipermail/kexec/2016-July/016686.html

The issue is the end address in a memory range can be handled
differently across various architectures.
So we are in a messy situation.

Thanks,
-Takahiro AKASHI



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

      reply	other threads:[~2016-09-29 14:27 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-07  4:33 [PATCH v3 0/8] (kexec-tools) arm64: add kdump support AKASHI Takahiro
2016-09-07  4:33 ` [PATCH v3 1/8] arm64: identify PHYS_OFFSET correctly AKASHI Takahiro
2016-09-27 15:49   ` Pratyush Anand
2016-09-28  7:48     ` AKASHI Takahiro
2016-10-24 23:02       ` Goel, Sameer
2016-09-07  4:33 ` [PATCH v3 2/8] kexec: generalize and rename get_kernel_stext_sym() AKASHI Takahiro
2016-10-06 13:28   ` Matthias Brugger
2016-10-07  4:18     ` Dave Young
2016-10-07  6:41       ` Pratyush Anand
2016-10-07  6:44     ` Pratyush Anand
2016-09-07  4:33 ` [PATCH v3 3/8] arm64: kdump: identify memory regions AKASHI Takahiro
2016-09-07  4:33 ` [PATCH v3 4/8] arm64: kdump: add elf core header segment AKASHI Takahiro
2016-09-07  4:33 ` [PATCH v3 5/8] arm64: kdump: set up kernel image segment AKASHI Takahiro
2016-09-07  4:33 ` [PATCH v3 6/8] arm64: kdump: set up other segments AKASHI Takahiro
2016-09-07  4:34 ` [PATCH v3 7/8] arm64: kdump: add DT properties to crash dump kernel's dtb AKASHI Takahiro
2016-09-07  4:34 ` [PATCH v3 8/8] arm64: kdump: Add support for binary image files AKASHI Takahiro
2016-09-29  7:52 ` [PATCH v3 0/8] (kexec-tools) arm64: add kdump support Simon Horman
2016-09-29  8:18   ` AKASHI Takahiro
2016-09-29  8:39     ` Simon Horman
2016-09-29 14:26       ` AKASHI Takahiro [this message]

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=20160929142646.GB5218@localhost \
    --to=takahiro.akashi@linaro.org \
    --cc=geoff@infradead.org \
    --cc=horms@verge.net.au \
    --cc=kexec@lists.infradead.org \
    --cc=panand@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.