kdump without the kexec

[Lei Wen]

On Tue, May 10, 2011 at 3:48 PM, WANG Cong <xiyou.wangcong at gmail.com> wrote:
> On Mon, 09 May 2011 15:04:42 +0800, Lei Wen wrote:
>
>> Hi Cong,
>>
>> On Mon, May 9, 2011 at 2:42 PM, WANG Cong
>> <xiyou.wangcong at gmail.com> wrote:
>>> On Sun, 08 May 2011 23:31:30 +0800, Lei Wen wrote:
>>>
>>>> Hi Bernhard,
>>>>
>>>> On Sat, May 7, 2011 at 3:55 PM, Bernhard Walle
>>>> <bernhard at bwalle.de> wrote:
>>>>> * Lei Wen <adrian.wenl at gmail.com>
>>>>> [2011-05-06 16:33]:
>>>>>>
>>>>>> Is there any existed solution that could make the kdump without the
>>>>>> kexec? For some kind of system hang, always hardware bug, or
>>>>>> software deadlock, which could not trigger the kernel oops, so that
>>>>>> the first kernel cannot load the second kernel
>>>>>> with kexec tool. The only way here is to directly press the reset
>>>>>> key.
>>>>>>
>>>>>> We could be assure that the ddr memory would not be corrupted by
>>>>>> this way of reset
>>>>>> (for we don't shutdown the ddr power during the reset). So my
>>>>>> question is that whether
>>>>>> we could take use of bootloader, like the u-boot, to pretend we are
>>>>>> loading the second kernel
>>>>>> after the reset behavior and then perform the kdump process?
>>>>>
>>>>> Did you try sysrq-c? Which platform? Most of them have the concept of
>>>>> a NMI that also can trigger kdump.
>>>>>
>>>>>
>>>> For some case, the sysrq-c also cannot help, as the cpu is not
>>>> responding anymore for some
>>>> hw bug. I am running on arm board, there is no NMI concept on it... So
>>>> the only help is to put the hw reset and wish the bootloader do the
>>>> task which is expected
>>>> done by the kexec...
>>>
>>> Then kdump can't help in this case.
>>>
>>> And I am afraid you can't use the normal bootloader (e.g. grub, uboot),
>>> because we load the second kernel *while* running the first kernel,
>>> which means, for example, on x86 we are in protect mode after the
>>> kernel boots, not in the real mode in which grub starts.
>>>
>>> What's more, kdump will not hw-reset the devices unless you add
>>> "reset_devices" to the second kernel.
>>>
>> I see...
>> But what I am care is the memory dump done by the kdump. If I could boot
>> the second kernel without break the first kernel's space, that by put
>> the second kernel just in the space that has been reserved by the first
>> kernel. Is that possible to use the bootloader to perform such task?
>>
>> The devices state is not really cared by us, for the only interesting
>> point is the
>> memory context left by the first kernel.
>
> You need to pass correct kernel parameters to the second kernel to make
> this happen, kexec uses "memmap=exactmap memmap=XXX ..." to describe the
> memory map used by the second kernel.
>
> This is _not_ hard for normal bootloaders, the problem is still that you
> need to load the second kernel before the first kernel crashes and during
> the first kernel is running.
>
Thanks for this hint. :) I would have it a try.

Best regards,
Lei