From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XUysG-0004Qc-7O for ltp-list@lists.sourceforge.net; Fri, 19 Sep 2014 14:09:24 +0000 Received: from mx1.redhat.com ([209.132.183.28]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1XUysF-0000P3-2f for ltp-list@lists.sourceforge.net; Fri, 19 Sep 2014 14:09:24 +0000 Date: Fri, 19 Sep 2014 09:22:36 -0400 From: Vivek Goyal Message-ID: <20140919132236.GB2190@redhat.com> References: <145412866.25258463.1411119061796.JavaMail.zimbra@redhat.com> <293476264.25264480.1411120345360.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <293476264.25264480.1411120345360.JavaMail.zimbra@redhat.com> Subject: Re: [LTP] [RFC] autokdump - automated kdump testsuite List-Id: Linux Test Project General Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ltp-list-bounces@lists.sourceforge.net To: CAI Qian Cc: ltp-list , kexec kdump redhat mailing list , kexec , linux-kernel , crash-utility 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