On Thu, Jul 09, 2009 at 04:17:22PM +0900, Ken'ichi Ohmichi wrote:
>
> Hi Simon,
>
> Thank you so much for your review and comment.
>
> I have one question.
> Should I resend the patch to LKML with your "Acked-by:" tag for merging it ?
> Or isn't that necessary ?
I think sending it to LKML with the acked-by would be a good idea.
>
> Thanks
> Ken'ichi Ohmichi
>
> Simon Horman wrote:
> > On Thu, Jul 09, 2009 at 09:43:19AM +0900, Ken'ichi Ohmichi wrote:
> >> Hi Simon,
> >>
> >> Thank you for the comment.
> >>
> >> Simon Horman wrote:
> >>> On Wed, Jul 08, 2009 at 01:38:59PM +0900, Ken'ichi Ohmichi wrote:
> >>>> Hi,
> >>>>
> >>>> This patch enables a kdump if 2nd-kernel is loaded.
> >>>> (The patch is based on linux-2.6.31-rc2.)
> >>>>
> >>>> Now, a kdump is enabled if a kernel parameter "oops=panic" is specified and
> >>>> 2nd-kernel is loaded. I think that a kdump should be enabled regardless of
> >>>> "oops=panic" if 2nd-kernel is loaded, because a system administrator loads
> >>>> 2nd-kernel for enabling a kdump.
> >>> I'm not sure that I like this change. To my mind, panic on oops
> >>> should only occur if specifically requested.
> >> My patch does not make panic_on_oops effective when 2nd-kernel is loaded,
> >> and it makes a kdump effective.
> >>
> >> kexec_should_crash() is called only by oops_end() for checking whether to
> >> call crash_kexec(). crash_kexec() is not panic, and I feel it is better
> >> that crash_kexec() is called when 2nd-kernel is loaded.
> >>
> >>
> >> I tried to test a kdump on linux-2.6.31-rc1 *without* a kernel parameter
> >> "oops=panic" by `echo c > /proc/sysrq-trigger`, but a kdump did not work
> >> because a kdump, which is occurred by `echo c > /proc/sysrq-trigger`, has
> >> been changed to a NULL pointer error instead of calling crash_kexec()
> >> since linux-2.6.31-rc1. Then I tried to boot linux-2.6.31-rc1 *with* a
> >> kernel parameter "oops=panic", the kernel got a panic while kernel booting
> >> due to a problem other than a kdump.
> >> So I think a kdump should be enabled when 2nd-kernel is loaded.
> >
> > Hi,
> >
> > thanks for the more detailed explanation. I've reconsidered my position
> > and actually I think that I quite like your idea - it does indeed make
> > sense for kdump to occur if a kdump kernel has been loaded.
> >
> > Acked-by: Simon Horman <horms at verge.net.au>
> >
> >> Thanks
> >> Ken'ichi Ohmichi
> >>
> >>>> Signed-off-by: Ken'ichi Ohmichi <oomichi at mxs.nes.nec.co.jp>
> >>>> ---
> >>>> --- a/kernel/kexec.c 2009-07-08 12:30:26.000000000 +0900
> >>>> +++ b/kernel/kexec.c 2009-07-08 12:38:08.000000000 +0900
> >>>> @@ -57,6 +57,8 @@ struct resource crashk_res = {
> >>>>
> >>>> int kexec_should_crash(struct task_struct *p)
> >>>> {
> >>>> + if (kexec_crash_image)
> >>>> + return 1;
> >>>> if (in_interrupt() || !p->pid || is_global_init(p) || panic_on_oops)
> >>>> return 1;
> >>>> return 0;
> >>>>
> >>>> _______________________________________________
> >>>> kexec mailing list
> >>>> kexec at lists.infradead.org
> >>>> http://lists.infradead.org/mailman/listinfo/kexec
> >>> _______________________________________________
> >>> kexec mailing list
> >>> kexec at lists.infradead.org
> >>> http://lists.infradead.org/mailman/listinfo/kexec
> >>>
> >>
> >> _______________________________________________
> >> kexec mailing list
> >> kexec at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/kexec
> >
>
