[LTP] [RFC] [KDUMP] [PROPOSED WORK] kdump on Xen hypervisor and guests, more tests for utilities, like makedumpfile, mkdumprd, kexec etc

[Cai Qian]

Hi Subrata,

From: Subrata Modak <subrata at linux.vnet.ibm.com>
Subject: Re: [LTP] [RFC] [KDUMP] [PROPOSED WORK] kdump on Xen hypervisor and guests, more tests for utilities, like makedumpfile, mkdumprd, kexec etc
Date: Mon, 11 Aug 2008 19:02:47 +0530

> Cai,
> 
> Any headway in this front ?
> 

I have all test cases finished, but I am working on implementing a
suitable harness to run those tests.

CaiQian

> Regards--
> Subrata
> 
> On Thu, 2008-07-24 at 05:11 +0530, Subrata Modak wrote:
> > Hi Cai,
> > 
> > Some patches in Bits and Pieces regarding this nearby ?
> > 
> > Regards--
> > Subrata
> > 
> > > 
> > > Yes. Initally, I put this item to a relative low priority, partly
> > > because kdump config options and init scripts are tend to be
> > > distro-specific, so it won't be easy to write portable tests for
> > > different distros. In addition, lots of config options are not easy to
> > > be tested automately, like raw disk target, vfat disk target, and
> > > network target etc, as testers have to setup those name manually. But,
> > > you are right, those are high priority tests for kexec/kdump in distro
> > > release, we tested most of those options manually for RHEL anyway and we
> > > had some automated tests of it, which I'll try to submit to LTP as many
> > > as possible. For those manual tests, I'll also try to find some ways to
> > > automate them. For example, for different dump targets, it is possible
> > > to verify the generated initrd file as expected.
> > > 
> > > > 
> > > > > == increase coverages for new kexec/kdump development efforts ==
> > > > > - new reserved region syntax in Kernel.
> > > > 
> > > > Another important thing we need to focus on is driver testing. Drivers
> > > > can fail to initialize in second kernel and kdump will fail. Can we do
> > > > something so that we can do following.
> > > >
> > > 
> > > That isn't something I have not thought of. For RHEL release testing, we
> > > will have a workflow to run those tests on any storage/network drivers,
> > > and it will report back testing results and driver matrix. However, this
> > > workflow is very distro-specific, and depends on the test farm it is
> > > using, so it does not make any sense to put it here.
> > > 
> > > > - Collect the machine statistics on which kdump was tested and send
> > > >   the reports to a common place. Especially capture the storage/network
> > > >   driver data which can be probably be available through LTP site.
> > > > 
> > > 
> > > That sounds like a good idea to me.
> > > 
> > > > - Also capture how much memory was reserved on what architecture and
> > > >   whether it worked or not. This will help us verify for sure that how
> > > >  much memory to reserve for second kernel on various architectures.
> > > >
> > > 
> > > This is something could be done. I'll have a look at it.
> > > 
> > > Thanks,
> > > CaiQian
> > > 
> > > > Thanks
> > > > Vivek
> > 
> > 
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> > Build the coolest Linux based applications with Moblin SDK & win great prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Ltp-list mailing list
> > Ltp-list at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/ltp-list
>