All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vivek Goyal <vgoyal@redhat.com>
To: CAI Qian <caiqian@redhat.com>
Cc: ltp-list <ltp-list@lists.sourceforge.net>,
	kexec kdump redhat mailing list <kexec-kdump-list@redhat.com>,
	kexec <kexec@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	crash-utility <crash-utility@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

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

WARNING: multiple messages have this Message-ID (diff)
From: Vivek Goyal <vgoyal@redhat.com>
To: CAI Qian <caiqian@redhat.com>
Cc: ltp-list <ltp-list@lists.sourceforge.net>,
	kexec kdump redhat mailing list <kexec-kdump-list@redhat.com>,
	kexec <kexec@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	crash-utility <crash-utility@redhat.com>
Subject: Re: [LTP] [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

------------------------------------------------------------------------------
Slashdot TV.  Video for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

WARNING: multiple messages have this Message-ID (diff)
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

  reply	other threads:[~2014-09-19 14:09 UTC|newest]

Thread overview: 27+ 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  9:52   ` CAI Qian
2014-09-19  9:52   ` [LTP] " CAI Qian
2014-09-19 13:22   ` Vivek Goyal [this message]
2014-09-19 13:22     ` Vivek Goyal
2014-09-19 13:22     ` [LTP] " Vivek Goyal
2014-09-19 13:33     ` Vivek Goyal
2014-09-19 13:33       ` Vivek Goyal
2014-09-19 13:33       ` [LTP] " Vivek Goyal
2014-09-22 13:00     ` CAI Qian
2014-09-22 13:00       ` CAI Qian
2014-09-22 13:00       ` [LTP] " CAI Qian
2014-09-22 14:47       ` Vivek Goyal
2014-09-22 14:47         ` Vivek Goyal
2014-09-22 14:47         ` [LTP] " Vivek Goyal
2014-09-23  2:53         ` CAI Qian
2014-09-23  2:53           ` CAI Qian
2014-09-23  2:53           ` [LTP] " CAI Qian
2014-09-23 12:09           ` Vivek Goyal
2014-09-23 12:09             ` Vivek Goyal
2014-09-23 12:09             ` [LTP] " Vivek Goyal
2014-09-22  9:07   ` Dave Young
2014-09-22  9:07     ` Dave Young
2014-09-22  9:07     ` [LTP] " Dave Young
2014-09-22  9:12   ` Dave Young
2014-09-22  9:12     ` Dave Young
2014-09-22  9:12     ` [LTP] " 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 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.