On Tue, Jul 24, 2018 at 08:31:54AM +0200, Simon Horman wrote: > On Tue, Jul 17, 2018 at 02:13:42AM +0530, Bhupesh Sharma wrote: > > Hi Akashi, > > > > On 07/09/2018 12:41 PM, AKASHI Takahiro wrote: > > > Bhupesh, Simon, > > > > > > #I'm afraid that I gonna rehash the old discussion. > > > > > > Looking into ppc's kexec-tools code, I found that ppc version of > > > this tool has a similar feature and it saves a new dtb into a file, > > > named "debug.dtb." > > > See save_fixed_up_dtb() in kexec/arch/ppc/fixup_dtb.c > > > > > > Even if it is a debug feature, we'd better go in the same way > > > (if possible). > > > > Thanks for sharing the same. > > > > I had a look earlier also at the ppc - "debug.dtb" code in kexec-tools, but > > this is again fails to fulfill the same purpose that we are trying to > > resolve for early primary kernel crash(es) on arm64 machines, because of > > which we are not able to reach the command prompt with the primary kernel > > itself. > > > > We would need to either reach the command prompt to dump out/save the > > "debug.dtb" file when we are running the primary kernel (which is > > unfortunately not always possible wit latest kernels on some of the arm64 > > machines), Although I'm not sure how it cannot be possible, > or use some initramfs scriptware to dump out the same to some > > secondary storage device (nfs server or usb stick). > > > > So, I would still suggest to stick with the approach I proposed for now (and > > we can take a similar approach as ppc for arm64 later on) once we have > > kexec, kdump and other user-space utilities (which rely on the kexec kernel > > framework) working stably on arm64 machines (with latest upstream kernels). > > That sounds like a reasonable argument to me. > > Akashi, what do you think? it's fine to me, too. -Takahiro AKASHI _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
