Hi Simon, Simon Horman wrote: > 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. OK, I will do it. 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 > > _______________________________________________ > kexec mailing list > kexec at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec >