Hi Arun, On Fri, 2014-07-11 at 21:13 +0530, Arun Chandran wrote: > I tried kexec reboot with my modified kexec-tools and got a nice kernel panic. > Please find the error log attached. > There is only dtb file related change in the kernel sources, as given below. > > ########### > cpu-release-addr = <0x1 0x0000fff8>; > - cpu-return-addr = <0 0> > + cpu-return-addr = <0x0 0x0>; > ########### > > I just assigned a random value to "cpu-return-addr" in my dtb file; You need the proper cpu-return-addr value. Because cpu-return-addr was zero, kexec sent all your secondary processors back to secondary_startup, and is why you see that in your error log. I put in a hack for zero cpu-return-addr in my latest version. Please try it. If you use the same kernel for both the 1st and 2nd stage it should work. > Do you have any idea how to find out that value for my hardware? It is a property of your bootloader, not hardware. Ask your bootloader maintainer if you can, or check the bootloader sources. For the rtsm_ve_aemv8a model bootwrapper I set cpu-return-addr to <0x0 0x80000000> because the bootwrapper linker script puts _start at PHYS_OFFSET, which is 0x80000000 for that platform. https://git.kernel.org/cgit/linux/kernel/git/mark/boot-wrapper-aarch64.git/tree/model.lds.S#n30 > My hardware uses spin-table method for SMP. As you said there > is a bug in kexec for spin-table method, what about trying it without > CONFIG_SMP? Does your code support that? CONFIG_SMP=n should work, but I haven't tried it in a long time. -Geoff
