From: Vivek Goyal <vgoyal@redhat.com>
To: CAI Qian <caiqian@redhat.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
ltp-list <ltp-list@lists.sourceforge.net>,
crash-utility <crash-utility@redhat.com>,
kexec <kexec@lists.infradead.org>,
kexec kdump redhat mailing list <kexec-kdump-list@redhat.com>
Subject: Re: [RFC] autokdump - automated kdump testsuite
Date: Fri, 19 Sep 2014 09:22:36 -0400 [thread overview]
Message-ID: <20140919132236.GB2190@redhat.com> (raw)
In-Reply-To: <293476264.25264480.1411120345360.JavaMail.zimbra@redhat.com>
On Fri, Sep 19, 2014 at 05:52:25AM -0400, CAI Qian wrote:
> I plan to release an automated kdump testsuite that will be
So will this be a standalone test suit? Can it be merged with
something already existing say, LTP.
> focus on testing kernel and the crash utility. It should work
> for all major distros since it will use none of distro-specific
> stuff, and also support different arches including x86, ARM,
> PPC64 and s390x.
>
> It does the following:
> 1) check if there is a memory reserved for kdump. If not,
> reserve the memory and reboot the system.
> 2) once the system is back, load kexec on panic and
> prepare a separate initramfs that including needed
> modules to load a local filesystem and necessary utilities
So you will write logic to prepare custom initramfs or will rely
on dracut or some other utility for that.
> in order to analyse /proc/vmcore in the 2nd kernel.
> 3) trigger the system crash using methods like sysrq-c, NMI,
> and panic_on_hung_task etc.
> 4) in the 2nd kernel, mount a filesystem and use the crash
> utility to analyse /proc/vmcore. Then, gather the analyse
> logs, serial console output, dmesg etc into the filesystem.
Why not save core and boot back in first kernel and then analyze.
Trying to work directly with /proc/vmcore does not test makedumfile
which everybody uses. Also it will require more memory to be reserved
and packing crash and debug vmlinux into initramfs.
I think being able to test makedumpfile also is the key here.
Thanks
Vivek
> 5) reboot back into the 1st kernel.
>
> implementation:
> It will setup a daemon to handle reboots.
>
> plan:
> I might also to test the makedumpfile all together later.
> CAI Qian
next prev parent reply other threads:[~2014-09-19 14:09 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <145412866.25258463.1411119061796.JavaMail.zimbra@redhat.com>
2014-09-19 9:52 ` [RFC] autokdump - automated kdump testsuite CAI Qian
2014-09-19 13:22 ` Vivek Goyal [this message]
2014-09-19 13:33 ` Vivek Goyal
2014-09-22 13:00 ` CAI Qian
2014-09-22 14:47 ` Vivek Goyal
2014-09-23 2:53 ` CAI Qian
2014-09-23 12:09 ` Vivek Goyal
2014-09-22 9:07 ` Dave Young
2014-09-22 9:12 ` Dave Young
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=20140919132236.GB2190@redhat.com \
--to=vgoyal@redhat.com \
--cc=caiqian@redhat.com \
--cc=crash-utility@redhat.com \
--cc=kexec-kdump-list@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ltp-list@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).