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

[Subrata Modak <subrata@linux.vnet.ibm.com>]

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


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