[PATCH] 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.

Signed-off-by: Mohan Kumar M <redacted>
---
 arch/powerpc/kernel/head_64.S |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 84856be..8934500 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S

@@ -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

Mohan Kumar M writes:

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.

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.

Paul Mackerras wrote:

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?

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.