kdump without the kexec

[WANG Cong]

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.