* kdump without the kexec @ 2011-05-06 14:33 Lei Wen 2011-05-07 7:55 ` Bernhard Walle 0 siblings, 1 reply; 7+ messages in thread From: Lei Wen @ 2011-05-06 14:33 UTC (permalink / raw) To: kexec Hi, 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? Best regards, Lei _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: kdump without the kexec 2011-05-06 14:33 kdump without the kexec Lei Wen @ 2011-05-07 7:55 ` Bernhard Walle 2011-05-08 15:31 ` Lei Wen 0 siblings, 1 reply; 7+ messages in thread From: Bernhard Walle @ 2011-05-07 7:55 UTC (permalink / raw) To: kexec * Lei Wen <adrian.wenl@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. Regards, Bernhard _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: kdump without the kexec 2011-05-07 7:55 ` Bernhard Walle @ 2011-05-08 15:31 ` Lei Wen 2011-05-09 6:42 ` WANG Cong 0 siblings, 1 reply; 7+ messages in thread From: Lei Wen @ 2011-05-08 15:31 UTC (permalink / raw) To: Bernhard Walle; +Cc: kexec Hi Bernhard, On Sat, May 7, 2011 at 3:55 PM, Bernhard Walle <bernhard@bwalle.de> wrote: > * Lei Wen <adrian.wenl@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... Best regards, Lei _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: kdump without the kexec 2011-05-08 15:31 ` Lei Wen @ 2011-05-09 6:42 ` WANG Cong 2011-05-09 7:04 ` Lei Wen 0 siblings, 1 reply; 7+ messages in thread From: WANG Cong @ 2011-05-09 6:42 UTC (permalink / raw) To: kexec 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@bwalle.de> wrote: >> * Lei Wen <adrian.wenl@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. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: kdump without the kexec 2011-05-09 6:42 ` WANG Cong @ 2011-05-09 7:04 ` Lei Wen 2011-05-10 7:48 ` WANG Cong 0 siblings, 1 reply; 7+ messages in thread From: Lei Wen @ 2011-05-09 7:04 UTC (permalink / raw) To: WANG Cong; +Cc: kexec Hi Cong, On Mon, May 9, 2011 at 2:42 PM, WANG Cong <xiyou.wangcong@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@bwalle.de> wrote: >>> * Lei Wen <adrian.wenl@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. Thanks, Lei _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: kdump without the kexec 2011-05-09 7:04 ` Lei Wen @ 2011-05-10 7:48 ` WANG Cong 2011-05-17 14:49 ` Lei Wen 0 siblings, 1 reply; 7+ messages in thread From: WANG Cong @ 2011-05-10 7:48 UTC (permalink / raw) To: kexec 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@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@bwalle.de> wrote: >>>> * Lei Wen <adrian.wenl@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. _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: kdump without the kexec 2011-05-10 7:48 ` WANG Cong @ 2011-05-17 14:49 ` Lei Wen 0 siblings, 0 replies; 7+ messages in thread From: Lei Wen @ 2011-05-17 14:49 UTC (permalink / raw) To: WANG Cong; +Cc: kexec On Tue, May 10, 2011 at 3:48 PM, WANG Cong <xiyou.wangcong@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@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@bwalle.de> wrote: >>>>> * Lei Wen <adrian.wenl@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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-05-17 14:49 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-05-06 14:33 kdump without the kexec Lei Wen 2011-05-07 7:55 ` Bernhard Walle 2011-05-08 15:31 ` Lei Wen 2011-05-09 6:42 ` WANG Cong 2011-05-09 7:04 ` Lei Wen 2011-05-10 7:48 ` WANG Cong 2011-05-17 14:49 ` Lei Wen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox