lkml.org 
[lkml]   [2009]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [RFC][Patch x86-tip] add notifier before kdump
Hi Eric

Thanks for your comment.
I will consider the method you suggested. Thank you very much.

Best regards,
Jin Dongming

Eric W. Biederman wrote:
> Jin Dongming <jin.dongming@np.css.fujitsu.com> writes:
>
>> Vivek, Lon Hohberger
>>
>> Thanks for your comments.
>>
>> I also agree with your opinion, too. But I still have problems listed
>> as following.
>> 1. Nobody knows when the second kernel does not work well
>> 2. Too much time cost to startup the second kernel
>>
>> So I hope that following work could be done.
>> 1. Add some code before kdump to monitor the actions of second kernel
>> Something we worried about is that nobody knows when the kdump will not
>> work well. If the second kernel does not work well, nobody knows when
>> the best time is to restart. So we need to add some code such as setting
>> watchdog. If we want to monitor second kernel, some work need to be done
>> before it starts to work.
>
> Any extra work done in the crashing kernel decreases the likely hood
> of the second kernel working. If you want a watchdog I recommend you always
> run it and have the interval set large enough for the second kernel to boot
> before it starts petting it. That way no code needs to run after a kernel crash.
>
>> 2. Shorten the startup time of second kernel
>> I think that the purpose of second kernel is used for backup information
>> stored in memory to storage only. But the time cost is different
>> according to the system architecture. And also I think that there are
>> too many of device is not useful to get the memory information to
>> storage. I think the startup time of second kernel should be shortened.
>> I don't know much about second kernel, these are only my thought.
>
> The second kernel can be anything you like. Including a standalone executable
> if needed for very precise requirements. Any improvements in boot time for a
> normal linux image should apply to the dump kernel.
>
> Currently with a tight initrd and just dumping dmesg to disk I get away with
> a 20M crashkernel reservation, and it typically runs and does it's work before
> my watchdog fires.
>
> Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>




\
 
 \ /
  Last update: 2009-10-29 08:51    [W:0.035 / U:4.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site