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
