Fix kdump kernel hang issue with relocatable kernel patches

One of the relocatable kernel support patches assumes that the target address will be 0. But for kdump kernels (without relocation support) it will be 32MB. The following patch fixes this issue.

Fix kdump kernel issue

Kdump kernel without relocation support needs to be moved to PHYSICAL_START (ie 32MB) instead of 0. This patch fixes this issue.

---
 arch/powerpc/kernel/head_64.S |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

index 84856be..8934500 100644
@@ -1395,7 +1395,7 @@ _STATIC(__after_prom_start)
  *
  * Note: This process overwrites the OF exception vectors.
  */
-	li	r3,0			/* target addr */
+	LOAD_REG_IMMEDIATE(r3, PHYSICAL_START) /* target addr */
 	mr.	r4,r26			/* In some cases the loader may  */
 	beq	9f			/* have already put us at zero */
 	lis	r5,(copy_to_here - _stext)@ha

1.5.5.1


_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Hmmm. Is there any reason to continue to support non-relocatable 64-bit kernels being kdump kernels? In other words, for 64-bit, couldn't we make CONFIG_CRASH_DUMP depend on CONFIG_RELOCATABLE?

I don't think we want to try to support two different modes of operation for a kdump kernel, and I don't see any value in continuing to support PHYSICAL_START > 0 for 64-bit non-relocatable kernels. (And when we can make 32-bit PIE kernels, I'll be making the same statement about 32-bit. :)

Paul.

We wanted to support legacy kdump feature on 64 bit kernels for some time. But if nobody needs the legacy kdump, we can make kdump depend on relocatable

Regards,
Mohan.

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec