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
