Leo,

On 19 January 2017 at 23:55, Leo Yan leo.yan@linaro.org wrote:

Hi all,

Sorry for spamming, I want to check if someone has finished the kdump enabling work on 96boards? Particularly I'm interesting in enabling on DB410c or Hikey boards.

Kdump is still on the way of upstream :)

The flow is as below: First kernel booting `-> Wartchdog reset `-> second kernel booting `-> Dump DDR by USB port or into SD card

Due kdump enabling involves many components and need take care the memory regions allocation for ARM-TF, UEFI, kernels; so if you have made some progress for this, please let me know and this could save much time to avoid duplicate works.

As far as the memory allocation is concerned, you only have to specify the size of the region in a kernel command line. The kernel will take care of all the other things.

I almost all the time test my kdump on fast model, but am also sure that it works on Hikey.

If you see any problems, I'm happy to help fix them with you.

Thanks, -Takahiro AKASHI

Thanks, Leo Yan _______________________________________________ Dev mailing list Dev@lists.96boards.org https://lists.96boards.org/mailman/listinfo/dev

On 20 January 2017 at 18:09, Leo Yan leo.yan@linaro.org wrote:

Hi AKASHI,

On Fri, Jan 20, 2017 at 11:05:40AM +0900, AKASHI, Takahiro wrote:

...

Leo,

On 19 January 2017 at 23:55, Leo Yan leo.yan@linaro.org wrote:

...

Hi all,

Sorry for spamming, I want to check if someone has finished the kdump enabling work on 96boards? Particularly I'm interesting in enabling on DB410c or Hikey boards.

Kdump is still on the way of upstream :)

Thanks for the info. I'm using latest mainline kernel, so do you think there have some other offline patches which are missed on mainline kernel and I should note?

You need to apply my latest kdump patchset, currently v29 and soon v30.

...

...

The flow is as below: First kernel booting `-> Wartchdog reset `-> second kernel booting `-> Dump DDR by USB port or into SD card

Due kdump enabling involves many components and need take care the memory regions allocation for ARM-TF, UEFI, kernels; so if you have made some progress for this, please let me know and this could save much time to avoid duplicate works.

As far as the memory allocation is concerned, you only have to specify the size of the region in a kernel command line. The kernel will take care of all the other things.

I almost all the time test my kdump on fast model, but am also sure that it works on Hikey.

Great! So I just need follow the steps in the doc Documentation/kdump/kdump.txt,

I believe so.

Thanks, -Takahiro AKASHI

or you have suggestion for ARM64 or Hikey specific?

...

If you see any problems, I'm happy to help fix them with you.

Thanks in advance :)

...

Thanks, -Takahiro AKASHI

On Fri, Jan 20, 2017 at 11:05:40AM +0900, AKASHI, Takahiro wrote:

[...]

I almost all the time test my kdump on fast model, but am also sure that it works on Hikey.

If you see any problems, I'm happy to help fix them with you.

Now have enabled kdump/kexec/crash tools on Hikey. So I can dump memory for panic (and hard/soft lock to trigger panic) and use crash to analyze panic context. Thanks a lot for AKASHI's great job and help!

I have two following questions:

- It takes long time to boot dump-capture kernel, I saw code just to use software method to trigger CPU reset; but looks like the time is a bit long, usually will take > 1 minute. So is this expected? sorry I have not investigate more detailed for the latency.

- If system is deadlock on the bus (e.g. AXI, or DDR port), so all CPUs will stall for this case. We can rely on watchdog to trigger SoC reset and preserve DDR contect. After watchdog reset system, what's the general method to boot dump-capture kernel?

Thanks, Leo Yan

On Tue, Jan 24, 2017 at 04:34:40PM +0900, AKASHI, Takahiro wrote:

[...]

...

I have two following questions:

• It takes long time to boot dump-capture kernel, I saw code just to use software method to trigger CPU reset; but looks like the time is a bit long, usually will take > 1 minute. So is this expected? sorry I have not investigate more detailed for the latency.

It takes time to calculate and verify the hash for the second kernel in a purgatory, and it does matter also in kexec.

Pratyush has been proposing his solution here: http://lists.infradead.org/pipermail/kexec/2016-December/017874.html

Thanks for this.

...

• If system is deadlock on the bus (e.g. AXI, or DDR port), so all CPUs will stall for this case. We can rely on watchdog to trigger SoC reset and preserve DDR contect. After watchdog reset system, what's the general method to boot dump-capture kernel?

whether or not you can boot dump-capture kernel, do you think that you can reset the system, or at least the buses, without losing the contents of the system memory?

I have no expertise for hardware design, so from my limited understanding is hardware can distinguish the reset signal for SoC and for whole board.

Usually watchdog is to trigger SoC reset; so this signal doesn't connect with board level reset signal; in next power cycle we have much chance to preserve DDR content and dump it.

Thanks, Leo Yan

On Mon, Jan 23, 2017 at 11:34 PM, AKASHI, Takahiro takahiro.akashi@linaro.org wrote:

On 24 January 2017 at 15:51, Leo Yan leo.yan@linaro.org wrote:

[..]

...

• If system is deadlock on the bus (e.g. AXI, or DDR port), so all CPUs will stall for this case. We can rely on watchdog to trigger SoC reset and preserve DDR contect. After watchdog reset system, what's the general method to boot dump-capture kernel?

whether or not you can boot dump-capture kernel, do you think that you can reset the system, or at least the buses, without losing the contents of the system memory?

On the Qualcomm boards memory content is kept during a reset of the SoC, to allow post-mortem debugging. Qualcomm has a proprietary mechanism for extracting the memory content, but if you can trigger the execution of a separate kernel for memory dumping purposes this should work as well.

Regards, Bjorn