From: Russell King <rmk@armlinux.org.uk>
To: Bhupesh Sharma <bhsharma@redhat.com>
Cc: khalid.aziz@hp.com, kexec@lists.infradead.org,
AKASHI Takahiro <takahiro.akashi@linaro.org>,
Simon Horman <horms@verge.net.au>,
ebiederm@xmission.com, Bhupesh SHARMA <bhupesh.linux@gmail.com>,
Dave Young <dyoung@redhat.com>, Vivek Goyal <vgoyal@redhat.com>
Subject: Re: kdump in upstream kexec-tools
Date: Tue, 17 Apr 2018 13:51:35 +0100 [thread overview]
Message-ID: <20180417125134.GF23531@flint.armlinux.org.uk> (raw)
In-Reply-To: <CACi5LpNYx07WCXTYZ0ksDt1zwyEcO+JaAGypfLqC=3o8bHr1aQ@mail.gmail.com>
On Tue, Apr 17, 2018 at 04:20:00PM +0530, Bhupesh Sharma wrote:
> For e.g I use this tool on my arm64 board as follows:
>
> a. Read out the 'elfcorehdr' env variable passed to the crash kernel
> and pass the same as an argument to the tool:
>
> Assuming that the 'elfcorehdr' spans the range ->
> 0xffdf0000-0xffdf13ff, launch the tool as -
>
> # kdump
> Cannot find the start of the core dump
>
> # kdump 0xffdf0000 >> output_elf_file
>
> # file output_elf_file
> output: ELF 64-bit LSB core file ARM aarch64, version 1 (SYSV)
The contents should basically be the same (possibly with a different
section ordering) as /proc/vmcore in the crashdump kernel. If so,
kdump serves no useful purpose, and ends up confusing the situation
due to its inability to handle 32-bit ELF coredump files.
It seems to me that the presence of /proc/vmcore obsoletes the kdump
tool.
--
Russell King
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2018-04-17 12:52 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-17 4:50 kdump in upstream kexec-tools Bhupesh Sharma
2018-04-17 9:01 ` Russell King
2018-04-17 10:50 ` Bhupesh Sharma
2018-04-17 12:51 ` Russell King [this message]
2018-04-17 17:43 ` Bhupesh Sharma
2018-04-18 13:01 ` Simon Horman
2018-04-18 18:28 ` Russell King
2018-04-19 8:20 ` Simon Horman
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=20180417125134.GF23531@flint.armlinux.org.uk \
--to=rmk@armlinux.org.uk \
--cc=bhsharma@redhat.com \
--cc=bhupesh.linux@gmail.com \
--cc=dyoung@redhat.com \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=khalid.aziz@hp.com \
--cc=takahiro.akashi@linaro.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.