Re: [PATCH] Fix kdump kernel hang issue with relocatable kernel patches

2008-10-09 Thread Mohan Kumar M

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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


Re: [PATCH] Fix kdump kernel hang issue with relocatable kernel patches

2008-10-08 Thread Paul Mackerras
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev


[PATCH] Fix kdump kernel hang issue with relocatable kernel patches

2008-10-01 Thread Mohan Kumar M
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 <[EMAIL PROTECTED]>
---
 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

___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev