Re: [LTP] [RFC] [KDUMP] [PROPOSED WORK] kdump on Xen hypervisor and guests, more tests for utilities, like makedumpfile, mkdumprd, kexec etc
Hi Subrata, From: Subrata Modak <[EMAIL PROTECTED]> Subject: Re: [LTP] [RFC] [KDUMP] [PROPOSED WORK] kdump on Xen hypervisor and guests, more tests for utilities, like makedumpfile, mkdumprd, kexec etc Date: Tue, 12 Aug 2008 11:43:02 +0530 > On Tue, 2008-08-12 at 10:16 +0800, Cai Qian wrote: > > Hi Subrata, > > > > From: Subrata Modak <[EMAIL PROTECTED]> > > 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. > > Thanks Cai. Happy to know that you are done with all the test cases, and > only the integration part is pending. I am little bit confused when you > say that you are working on implementing a suitable harness to run those > tests. Does that mean that the way the present LTP-Kdump tests are run > is not suitable to accommodate the enhancements/additions that you are > doing to the LTP-Kdump ? > What I have already done is to create several basic building blocks for testing of Kdump. For example, setup-bare-metal, config-ext3, crash-sysrq-c, crash-lkdtm, analyse-crash etc. You probably could guess what they are doing from their names. Then, we could combine those building blocks to create test cases, which should give us more freedom and flexibility to test things. I am going to include some pre-defined test cases into LTP as well. I might propose new tests as LTP-kdump-ng. > I do not mind in having a nice harness within LTP for executing the > LTP-Kdump tests, but i would hope that the new harness should also > include the existing LTP-Kdump tests, so that you use the same (new > harness) to tests everything in LTP-Kdump. Let me know what you think > for the same. > The problem that I am trying to figure it out is that we need a suitable harness to schedule those tests and report results. For example, there is a test case is like the following, setup-bare-metal config-ext3:uuid crash-sysrq-c analyse-crash The first and the third steps requires to reboot the machine, so we need a harness could resume execution of tests after reboot. I am thinking of using cron job as in existing LTP-kdump tests, or a tests injector running as a daemon, or something else. New tests should incorporate all existing tests and coverage of Kdump in LTP. CaiQian > Regards-- > Subrata > > > > > 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. > > > > > > > > >
Re: [PATCH -v3 5/7] kexec jump: in sync with hibernation implementation
On Tue 2008-08-12 11:14:33, Huang Ying wrote: > Add device_pm_lock() and device_pm_unlock() in kernel_kexec() in sync > with current hibernation implementation. > > Signed-off-by: Huang Ying <[EMAIL PROTECTED]> Acked-by: Pavel Machek <[EMAIL PROTECTED]> -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -v3 3/7] kexec jump: check code size in control page
On Tue, Aug 12, 2008 at 11:14:28AM +0800, Huang Ying wrote: > Kexec/Kexec-jump require code size in control page is less than > PAGE_SIZE/2. This patch add link-time checking for this. > > ASSERT() of ld link script is used as the link-time checking > mechanism. > > Signed-off-by: Huang Ying <[EMAIL PROTECTED]> > > --- > arch/x86/kernel/machine_kexec_32.c |2 +- > arch/x86/kernel/relocate_kernel_32.S | 10 +++--- > arch/x86/kernel/vmlinux_32.lds.S |6 ++ > include/asm-x86/kexec.h |4 > 4 files changed, 18 insertions(+), 4 deletions(-) > > --- a/arch/x86/kernel/machine_kexec_32.c > +++ b/arch/x86/kernel/machine_kexec_32.c > @@ -138,7 +138,7 @@ void machine_kexec(struct kimage *image) > } > > control_page = page_address(image->control_code_page); > - memcpy(control_page, relocate_kernel, PAGE_SIZE/2); > + memcpy(control_page, relocate_kernel, KEXEC_CONTROL_CODE_MAX_SIZE); > > relocate_kernel_ptr = control_page; > page_list[PA_CONTROL_PAGE] = __pa(control_page); > --- a/arch/x86/kernel/relocate_kernel_32.S > +++ b/arch/x86/kernel/relocate_kernel_32.S > @@ -20,10 +20,11 @@ > #define PAGE_ATTR (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | _PAGE_DIRTY) > #define PAE_PGD_ATTR (_PAGE_PRESENT) > > -/* control_page + PAGE_SIZE/2 ~ control_page + PAGE_SIZE * 3/4 are > - * used to save some data for jumping back > +/* control_page + KEXEC_CONTROL_CODE_MAX_SIZE > + * ~ control_page + PAGE_SIZE are used as data storage and stack for > + * jumping back > */ > -#define DATA(offset) (PAGE_SIZE/2+(offset)) > +#define DATA(offset) (KEXEC_CONTROL_CODE_MAX_SIZE+(offset)) > > /* Minimal CPU state */ > #define ESP DATA(0x0) > @@ -376,3 +377,6 @@ swap_pages: > popl%ebx > popl%ebp > ret > + > + .globl kexec_control_code_size > +.set kexec_control_code_size, . - relocate_kernel > --- a/include/asm-x86/kexec.h > +++ b/include/asm-x86/kexec.h > @@ -41,6 +41,10 @@ > # define PAGES_NR17 > #endif > > +#ifdef CONFIG_X86_32 > +# define KEXEC_CONTROL_CODE_MAX_SIZE 2048 > +#endif > + > #ifndef __ASSEMBLY__ > > #include > --- a/arch/x86/kernel/vmlinux_32.lds.S > +++ b/arch/x86/kernel/vmlinux_32.lds.S > @@ -209,3 +209,9 @@ SECTIONS > >DWARF_DEBUG > } > + > +/* Link time checks */ > +#include > + > +ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE, > + "kexec control code size is too big") Hi Huang, Will above ASSERT() still compile if CONFIG_KEXEC=n? If yes, then it looks good to me. Acked-by: Vivek Goyal <[EMAIL PROTECTED]> Thanks Vivek ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -v3 6/7] kexec jump: __ftrace_enabled_save/restore
On Tue, Aug 12, 2008 at 11:14:36AM +0800, Huang Ying wrote:
> Add __ftrace_enabled_save/restore, used to disable ftrace for a
> while. Now, this is used by kexec jump, which need a version without
> lock, for general situation, a locked version should be used.
>
> Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
>
> ---
> include/linux/ftrace.h | 21 +
> 1 file changed, 21 insertions(+)
>
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -98,6 +98,27 @@ static inline void tracer_disable(void)
> #endif
> }
>
> +/* Ftrace disable/restore without lock. Some synchronization mechanism
> + * must be used to prevent ftrace_enabled to be changed between
> + * disable/restore. */
> +static inline int __ftrace_enabled_save(void)
> +{
> +#ifdef CONFIG_FTRACE
> + int saved_ftrace_enabled = ftrace_enabled;
> + ftrace_enabled = 0;
> + return saved_ftrace_enabled;
> +#else
> + return 0;
> +#endif
> +}
> +
> +static inline void __ftrace_enabled_restore(int enabled)
> +{
> +#ifdef CONFIG_FTRACE
> + ftrace_enabled = enabled;
> +#endif
> +}
> +
> #ifdef CONFIG_FRAME_POINTER
> /* TODO: need to fix this for ARM */
> # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0))
I guess steven would like to see a patch which introduces both locked
and lockless versions and with a very good comment explaining in what
kind of unusual situation one can use the lockless version.
Thanks
Vivek
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH] kexec jump: fix code size checking
Fix building issue when CONFIG_KEXEC=n. Thanks to Vivek Goyal for his reminding. Signed-off-by: Huang Ying <[EMAIL PROTECTED]> --- include/asm-x86/kexec.h |3 +++ 1 file changed, 3 insertions(+) --- a/include/asm-x86/kexec.h +++ b/include/asm-x86/kexec.h @@ -43,6 +43,9 @@ #ifdef CONFIG_X86_32 # define KEXEC_CONTROL_CODE_MAX_SIZE 2048 +# ifndef CONFIG_KEXEC +# define kexec_control_code_size 0 +# endif #endif #ifndef __ASSEMBLY__ ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -v3 6/7] kexec jump: __ftrace_enabled_save/restore
On Tue, 2008-08-12 at 09:06 -0400, Vivek Goyal wrote:
> On Tue, Aug 12, 2008 at 11:14:36AM +0800, Huang Ying wrote:
> > Add __ftrace_enabled_save/restore, used to disable ftrace for a
> > while. Now, this is used by kexec jump, which need a version without
> > lock, for general situation, a locked version should be used.
> >
> > Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
> >
> > ---
> > include/linux/ftrace.h | 21 +
> > 1 file changed, 21 insertions(+)
> >
> > --- a/include/linux/ftrace.h
> > +++ b/include/linux/ftrace.h
> > @@ -98,6 +98,27 @@ static inline void tracer_disable(void)
> > #endif
> > }
> >
> > +/* Ftrace disable/restore without lock. Some synchronization mechanism
> > + * must be used to prevent ftrace_enabled to be changed between
> > + * disable/restore. */
> > +static inline int __ftrace_enabled_save(void)
> > +{
> > +#ifdef CONFIG_FTRACE
> > + int saved_ftrace_enabled = ftrace_enabled;
> > + ftrace_enabled = 0;
> > + return saved_ftrace_enabled;
> > +#else
> > + return 0;
> > +#endif
> > +}
> > +
> > +static inline void __ftrace_enabled_restore(int enabled)
> > +{
> > +#ifdef CONFIG_FTRACE
> > + ftrace_enabled = enabled;
> > +#endif
> > +}
> > +
> > #ifdef CONFIG_FRAME_POINTER
> > /* TODO: need to fix this for ARM */
> > # define CALLER_ADDR0 ((unsigned long)__builtin_return_address(0))
>
> I guess steven would like to see a patch which introduces both locked
> and lockless versions and with a very good comment explaining in what
> kind of unusual situation one can use the lockless version.
Have sent a locked version to Steven. And, there are some comments for
non-locked version, __ftrace_enabled_save() in above patch. What do you
think about it?
Best Regards,
Huang Ying
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec jump: fix code size checking
On Wed, Aug 13, 2008 at 09:04:35AM +0800, Huang Ying wrote: > Fix building issue when CONFIG_KEXEC=n. Thanks to Vivek Goyal for his > reminding. > > Signed-off-by: Huang Ying <[EMAIL PROTECTED]> > > --- > include/asm-x86/kexec.h |3 +++ > 1 file changed, 3 insertions(+) > > --- a/include/asm-x86/kexec.h > +++ b/include/asm-x86/kexec.h > @@ -43,6 +43,9 @@ > > #ifdef CONFIG_X86_32 > # define KEXEC_CONTROL_CODE_MAX_SIZE 2048 > +# ifndef CONFIG_KEXEC > +# define kexec_control_code_size0 > +# endif > #endif > > #ifndef __ASSEMBLY__ Is it impossible to skip the linker check in the !CONFIG_KEXEC case? ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec jump: fix code size checking
On Wed, 2008-08-13 at 12:47 +1000, Simon Horman wrote: > On Wed, Aug 13, 2008 at 09:04:35AM +0800, Huang Ying wrote: > > Fix building issue when CONFIG_KEXEC=n. Thanks to Vivek Goyal for his > > reminding. > > > > Signed-off-by: Huang Ying <[EMAIL PROTECTED]> > > > > --- > > include/asm-x86/kexec.h |3 +++ > > 1 file changed, 3 insertions(+) > > > > --- a/include/asm-x86/kexec.h > > +++ b/include/asm-x86/kexec.h > > @@ -43,6 +43,9 @@ > > > > #ifdef CONFIG_X86_32 > > # define KEXEC_CONTROL_CODE_MAX_SIZE 2048 > > +# ifndef CONFIG_KEXEC > > +# define kexec_control_code_size 0 > > +# endif > > #endif > > > > #ifndef __ASSEMBLY__ > > Is it impossible to skip the linker check in the !CONFIG_KEXEC case? It is possible. I think there are several ways to do that. 1) use #ifdef in vmlinux_32.lds.S, such as: #ifdef CONFIG_KEXEC ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE, "kexec control code size is too big") #endif 2) #define a macro for kexec check ld script in asm/kexec.h, such as: #define LD_CHECK_KEXEC()ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE, \ "kexec control code size is too big") and use that in vmlinux_32.lds.S. 3) #define kexec_control_code_size 0. So that the check can be passed always. And, code size = 0 is reasonable for no code (CONFIG_KEXEC=n). I think 3) is better. What do you think about? Best Regards, Huang Ying ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec jump: fix code size checking
Huang Ying <[EMAIL PROTECTED]> writes: > On Wed, 2008-08-13 at 12:47 +1000, Simon Horman wrote: >> On Wed, Aug 13, 2008 at 09:04:35AM +0800, Huang Ying wrote: >> > Fix building issue when CONFIG_KEXEC=n. Thanks to Vivek Goyal for his >> > reminding. >> > >> > Signed-off-by: Huang Ying <[EMAIL PROTECTED]> >> > >> > --- >> > include/asm-x86/kexec.h |3 +++ >> > 1 file changed, 3 insertions(+) >> > >> > --- a/include/asm-x86/kexec.h >> > +++ b/include/asm-x86/kexec.h >> > @@ -43,6 +43,9 @@ >> > >> > #ifdef CONFIG_X86_32 >> > # define KEXEC_CONTROL_CODE_MAX_SIZE 2048 >> > +# ifndef CONFIG_KEXEC >> > +# define kexec_control_code_size 0 >> > +# endif >> > #endif >> > >> > #ifndef __ASSEMBLY__ >> >> Is it impossible to skip the linker check in the !CONFIG_KEXEC case? > > It is possible. I think there are several ways to do that. > > 1) use #ifdef in vmlinux_32.lds.S, such as: > > #ifdef CONFIG_KEXEC > ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE, >"kexec control code size is too big") > #endif > > 2) #define a macro for kexec check ld script in asm/kexec.h, such as: > > #define LD_CHECK_KEXEC() ASSERT(kexec_control_code_size <= > KEXEC_CONTROL_CODE_MAX_SIZE, \ > "kexec control code size is too big") > > and use that in vmlinux_32.lds.S. > > 3) #define kexec_control_code_size 0. So that the check can be passed > always. And, code size = 0 is reasonable for no code (CONFIG_KEXEC=n). > > > I think 3) is better. What do you think about? 4) Put the code is a special section .text.kexec? and have the linker always do the size comparison and the computation of the section size. The fewer conditionals we have the less likely something is to break. Eric ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -v3 1/7] kexec jump: clean up #ifdef and comments
On Tue, 12 Aug 2008 11:14:21 +0800 Huang Ying <[EMAIL PROTECTED]> wrote: > xchg(&kexec_lock, 0); kernel/kexec.c: In function 'kernel_kexec': kernel/kexec.c:1501: warning: value computed is not used Is there any reason why we cannot use the more conventional test_and_set_bit() etc, rather than this peculiarity? Or perhaps spin_trylock? ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec jump: fix code size checking
On Wed, Aug 13, 2008 at 11:05:15AM +0800, Huang Ying wrote: > On Wed, 2008-08-13 at 12:47 +1000, Simon Horman wrote: > > On Wed, Aug 13, 2008 at 09:04:35AM +0800, Huang Ying wrote: > > > Fix building issue when CONFIG_KEXEC=n. Thanks to Vivek Goyal for his > > > reminding. > > > > > > Signed-off-by: Huang Ying <[EMAIL PROTECTED]> > > > > > > --- > > > include/asm-x86/kexec.h |3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > --- a/include/asm-x86/kexec.h > > > +++ b/include/asm-x86/kexec.h > > > @@ -43,6 +43,9 @@ > > > > > > #ifdef CONFIG_X86_32 > > > # define KEXEC_CONTROL_CODE_MAX_SIZE 2048 > > > +# ifndef CONFIG_KEXEC > > > +# define kexec_control_code_size0 > > > +# endif > > > #endif > > > > > > #ifndef __ASSEMBLY__ > > > > Is it impossible to skip the linker check in the !CONFIG_KEXEC case? > > It is possible. I think there are several ways to do that. > > 1) use #ifdef in vmlinux_32.lds.S, such as: > > #ifdef CONFIG_KEXEC > ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE, >"kexec control code size is too big") > #endif > > 2) #define a macro for kexec check ld script in asm/kexec.h, such as: > > #define LD_CHECK_KEXEC() ASSERT(kexec_control_code_size <= > KEXEC_CONTROL_CODE_MAX_SIZE, \ > "kexec control code size is too big") > > and use that in vmlinux_32.lds.S. > > 3) #define kexec_control_code_size 0. So that the check can be passed > always. And, code size = 0 is reasonable for no code (CONFIG_KEXEC=n). > > > I think 3) is better. What do you think about? Hi Huang, I think that 1) with possibly the slight variation of moving #include inside #ifdef CONFIG_KEXEC is better because it avoids introducing kexec_control_code_size, which is currently only used in arch/x86/kernel/relocate_kernel_32.S and arch/x86/kernel/vmlinux_32.lds.S, into kexec.h. /* Link time checks */ #ifdef CONFIG_KEXEC #include ASSERT(kexec_control_code_size <= KEXEC_CONTROL_CODE_MAX_SIZE, "kexec control code size is too big") #endif My second preference would be 3) as it seems simpler than 2). ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -v3 1/7] kexec jump: clean up #ifdef and comments
On Tue, 2008-08-12 at 20:49 -0700, Andrew Morton wrote: > On Tue, 12 Aug 2008 11:14:21 +0800 Huang Ying <[EMAIL PROTECTED]> wrote: > > > xchg(&kexec_lock, 0); > > kernel/kexec.c: In function 'kernel_kexec': > kernel/kexec.c:1501: warning: value computed is not used > > Is there any reason why we cannot use the more conventional > test_and_set_bit() etc, rather than this peculiarity? > > Or perhaps spin_trylock? Hi, Andrew, I think it is of no problem to replace xchg() with test_and_set_bit() or spin_trylock(). Hi, Eric, Do you have some reason to use xchg() instead of others? Best Regards, Huang Ying ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH -v3 1/7] kexec jump: clean up #ifdef and comments
Andrew Morton <[EMAIL PROTECTED]> writes: > On Tue, 12 Aug 2008 11:14:21 +0800 Huang Ying <[EMAIL PROTECTED]> wrote: > >> xchg(&kexec_lock, 0); > > kernel/kexec.c: In function 'kernel_kexec': > kernel/kexec.c:1501: warning: value computed is not used A good question is why we are warned. > Is there any reason why we cannot use the more conventional > test_and_set_bit() etc, rather than this peculiarity? > > Or perhaps spin_trylock? Totally odd. Let me stop and take a look and see what has been changed. The original code used a xchg based read copy update scheme, which was extremely compatible with a lot of goals. The primary one being no blocking paths in a successful kexec, and minimal dependence on library functions. We need that minimal dependence to handle the kexec on panic case. That doesn't rule out something like test_and_set_bit. Eric ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec jump: fix code size checking
On Tue, 2008-08-12 at 20:40 -0700, Eric W. Biederman wrote: [...] > 4) Put the code is a special section .text.kexec? and have the linker >always do the size comparison and the computation of the section size. > > The fewer conditionals we have the less likely something is to break. Yes. This one is good. But I think current one is acceptable too. Best Regards, Huang Ying ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] kexec jump: fix code size checking
On Wed, Aug 13, 2008 at 01:18:12PM +0800, Huang Ying wrote: > On Tue, 2008-08-12 at 20:40 -0700, Eric W. Biederman wrote: > [...] > > 4) Put the code is a special section .text.kexec? and have the linker > >always do the size comparison and the computation of the section size. > > > > The fewer conditionals we have the less likely something is to break. > > Yes. This one is good. But I think current one is acceptable too. If you really think that 1) is the best way Acked-by: Simon Horman <[EMAIL PROTECTED]> ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [LTP] [RFC] [KDUMP] [PROPOSED WORK] kdump on Xen hypervisor and guests, more tests for utilities, like makedumpfile, mkdumprd, kexec etc
Hi Cai, Thanks very much for explaining everything. Regards-- Subrata On Tue, 2008-08-12 at 16:48 +0800, Cai Qian wrote: > Hi Subrata, > > From: Subrata Modak <[EMAIL PROTECTED]> > Subject: Re: [LTP] [RFC] [KDUMP] [PROPOSED WORK] kdump on Xen hypervisor and > guests, more tests for utilities, like makedumpfile, mkdumprd, kexec etc > Date: Tue, 12 Aug 2008 11:43:02 +0530 > > > On Tue, 2008-08-12 at 10:16 +0800, Cai Qian wrote: > > > Hi Subrata, > > > > > > From: Subrata Modak <[EMAIL PROTECTED]> > > > 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. > > > > Thanks Cai. Happy to know that you are done with all the test cases, and > > only the integration part is pending. I am little bit confused when you > > say that you are working on implementing a suitable harness to run those > > tests. Does that mean that the way the present LTP-Kdump tests are run > > is not suitable to accommodate the enhancements/additions that you are > > doing to the LTP-Kdump ? > > > > What I have already done is to create several basic building blocks for > testing of Kdump. For example, setup-bare-metal, config-ext3, > crash-sysrq-c, crash-lkdtm, analyse-crash etc. You probably could guess > what they are doing from their names. Then, we could combine those > building blocks to create test cases, which should give us more freedom > and flexibility to test things. I am going to include some pre-defined > test cases into LTP as well. I might propose new tests as LTP-kdump-ng. > > > I do not mind in having a nice harness within LTP for executing the > > LTP-Kdump tests, but i would hope that the new harness should also > > include the existing LTP-Kdump tests, so that you use the same (new > > harness) to tests everything in LTP-Kdump. Let me know what you think > > for the same. > > > > The problem that I am trying to figure it out is that we need a suitable > harness to schedule those tests and report results. For example, there > is a test case is like the following, > > setup-bare-metal > config-ext3:uuid > crash-sysrq-c > analyse-crash > > The first and the third steps requires to reboot the machine, so we need > a harness could resume execution of tests after reboot. I am thinking of > using cron job as in existing LTP-kdump tests, or a tests injector > running as a daemon, or something else. > > New tests should incorporate all existing tests and coverage of Kdump in > LTP. > > CaiQian > > > Regards-- > > Subrata > > > > > > > > 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 >
