Re: Kexec support for PS3 (ppc64)

2008-03-06 Thread Mohan Kumar M
On Thu, Mar 06, 2008 at 04:55:04PM +0530, Rajasekaran Periyasamy wrote: Hi, I put a printk() in the early lines of early_parse_crashk() with KERN_EMERG, but not able to see that on the boot screen. I think the control is not transferred to early_parse_crashk() at all. With out this

Re: Kexec support for PS3 (ppc64)

2008-03-06 Thread Mohan Kumar M
On Thu, Mar 06, 2008 at 04:28:32PM +0530, Rajasekaran Periyasamy wrote: Hi All, Is KEXEC fully support ppc64 platform? Hi Rajasekaran, Kexec/kdump is fully supported on PPC64 platform. I am working on Kdump for ppc64 (PS3) platform, running 2.6.23 kernel built with KEXEC support. But

Re: Fwd: Kexec support for PS3 (ppc64)

2008-03-11 Thread Mohan Kumar M
On Tue, Mar 11, 2008 at 06:40:46PM -0700, Geoff Levand wrote: When the first stage kernel goes down it releases all hypervisor resources so that whatever boots next can successful open those resources. The frame buffer is one of those resources that are released, and after it is, there will

Re: Fwd: Kexec support for PS3 (ppc64)

2008-03-11 Thread Mohan Kumar M
On Tue, Mar 11, 2008 at 10:40:25PM -0700, Geoff Levand wrote: That is for the IBM pSeries. I can't see how it would work on the ps3. ps3 hvcalls are in lv1calls.h. Oh, okay. Just out of curiosity, how exactly did you 'use' it? We used the function plpar_put_term_char Regards, Mohan.

Re: Fwd: Kexec support for PS3 (ppc64)

2008-03-14 Thread Mohan Kumar M
On Fri, Mar 14, 2008 at 03:36:58AM -0700, Rajasekaran P wrote: On Tue, Mar 11, 2008 at 11:48 AM, Geoff Levand [EMAIL PROTECTED] wrote: Initially I made mistake by referring /proc/meminfo and thought the total RAM was 200M iB (actually it shows around 211MiB in /proc/meminfo excluding swap

Re: Fwd: Kexec support for PS3 (ppc64)

2008-03-14 Thread Mohan Kumar M
On Fri, Mar 14, 2008 at 04:18:52AM -0700, Rajasekaran P wrote: Yes,I built this kernel with CRASH_DUMP and VMCORE file system enabled. Moreover, I disabled SMP as well. My system kernel is (First kernel) is SMP enabled, does it matter? It should not matter. I dont get any message from

Re: Question about forcing kernel panic on PowerMac G5 by kexec command

2008-04-23 Thread Mohan Kumar M
Message- From: Mohan Kumar M [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 22, 2008 2:35 PM To: gib Cc: kexec@lists.infradead.org Subject: Re: Question about forcing kernel panic on PowerMac G5 by kexec command gib wrote: Hello all, I'm working on PowerMac G5 complied

Re: Question about forcing kernel panic on PowerMac G5 by kexec command

2008-05-23 Thread Mohan Kumar M
Mohan Kumar M wrote: gib wrote: Hi Mohan, Do you have only one entry for memory node in the /proc/device-tree directory? Yes, I have only one entry(for memory) in the /proc/device-tree directory. Do you know last good working version of kernel (for kdump) and try to boot into that kernel

Re: [PATCH] Let kexec work on IBM QS2x blade servers

2008-08-27 Thread Mohan Kumar M
Maxim Shchetynin wrote: Hello, please have a look at the following patch. This patch allows kexec to work on IBM QS2x blades. Would it be possible to apply this patch to a next kexec version? From: Maxim Shchetynin [EMAIL PROTECTED]. Signed-off-by: Maxim Shchetynin [EMAIL PROTECTED] ---

[PATCH] Remove legacy kdump kernel build support

2008-09-30 Thread Mohan Kumar M
-off-by: Mohan Kumar M [EMAIL PROTECTED] --- arch/powerpc/Kconfig|2 - arch/powerpc/include/asm/iommu.h|5 arch/powerpc/include/asm/kdump.h| 35 -- arch/powerpc/include/asm/page.h |1 - arch/powerpc/kernel/crash.c

[PATCH] Relocatable kdump kernel support in kexec-tools

2008-09-30 Thread Mohan Kumar M
. Signed-off-by: Mohan Kumar M [EMAIL PROTECTED] --- diff --git a/purgatory/arch/ppc64/v2wrap.S b/purgatory/arch/ppc64/v2wrap.S index b3563de..f69dad2 100644 --- a/purgatory/arch/ppc64/v2wrap.S +++ b/purgatory/arch/ppc64/v2wrap.S @@ -45,6 +45,7 @@ orisrn,rn,[EMAIL PROTECTED

[PATCH 2/2] Support for relocatable kdump kernel

2008-09-30 Thread Mohan Kumar M
will boot at the address where it was loaded by kexec-tools ie at the address reserved through crashkernel boot parameter. Now for kdump, both CONFIG_RELOCATABLE and CONFIG_CRASH_DUMP should be enabled and the same kernel can be used as production and kdump kernel. Signed-off-by: Mohan Kumar M [EMAIL

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

2008-10-01 Thread Mohan Kumar M
(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

[PATCH] Support for relocatable kdump kernel

2008-10-01 Thread Mohan Kumar M
-by: Mohan Kumar M [EMAIL PROTECTED] --- Documentation/kdump/kdump.txt | 14 ++-- arch/powerpc/Kconfig |4 +- arch/powerpc/include/asm/kdump.h | 16 arch/powerpc/kernel/crash_dump.c |2 + arch/powerpc/kernel/head_64.S | 60

Re: [PATCH] Remove legacy kdump kernel build support

2008-10-01 Thread Mohan Kumar M
Anton Vorontsov wrote: On Tue, Sep 30, 2008 at 06:18:28PM +0530, Mohan Kumar M wrote: Remove legacy kdump kernel build support Hi, I have submitted the patch to support relocatable kdump kernel with retaining legacy kdump build support. Regards, Mohan. Can we leave the legacy support

Re: [PATCH] powerpc: dtb and purgatory support for ppc32

2008-10-02 Thread Mohan Kumar M
Simon Horman wrote: On Thu, Oct 02, 2008 at 09:50:16AM +0200, Sebastian Siewior wrote: I'm not speaking on behalf of Kumar Gala, just on behalf of myself. Hi Horms, I would like to get some review of this patch by if possible. Also, I'm a little unclear of how it will interact with the

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

Re: [PATCH] Support for relocatable kdump kernel

2008-10-09 Thread Mohan Kumar M
Hi Paul, Thank you for the review. I will implement the changes you suggested and send the patches. Regards, Mohan. Mohan Kumar M writes: Support for relocatable kdump kernel [snip] @@ -1384,7 +1392,15 @@ _STATIC(__after_prom_start) /* process relocations for the final address

[PATCH] Support for relocatable kdump kernel

2008-10-12 Thread Mohan Kumar M
the changes suggested by Paul Mackerrass to avoid GOT use and to avoid two copies of the code. Signed-off-by: Mohan Kumar M [EMAIL PROTECTED] --- Documentation/kdump/kdump.txt | 14 ++--- arch/powerpc/Kconfig |8 ++- arch/powerpc/include/asm/kdump.h

Re: [PATCH] Support for relocatable kdump kernel

2008-10-16 Thread Mohan Kumar M
Paul Mackerras wrote: Mohan Kumar M writes: Support for relocatable kdump kernel @@ -1401,9 +1414,21 @@ _STATIC(__after_prom_start) beq 9f /* have already put us at zero */ li r6,0x100/* Start offset, the first 0x100

Re: [PATCH] Support for relocatable kdump kernel

2008-10-20 Thread Mohan Kumar M
Michael Ellerman wrote: Forwarded Message The purgatory code compares the signature and sets the __kdump_flag in head_64.S. During the boot up, kernel code checks __kdump_flag and if it is set, the kernel will behave as relocatable kdump kernel. This kernel will boot at the

Re: [PATCH] Support for relocatable kdump kernel

2008-10-21 Thread Mohan Kumar M
Michael Ellerman wrote: Does it? I see CONFIG_CRASH_DUMP depending on PPC64, so there is no 32-bit kdump possible. Or is someone working on it out-of-tree? IIUC Anton Vorontsov is working on the 32-bit kdump kernel support. Do you expect a function to do the checking in iommu.c? You'd

Re: [PATCH 3/3] powerpc/ppc64/kdump: better flag for running relocatable

2008-11-10 Thread Mohan Kumar M
Milton Miller wrote: On Oct 23, 2008, at 10:15 AM, Mohan Kumar M wrote: Hi Milton, My suggestions: Milton Miller wrote: i.e., [code snip 1] lwz r7,__run_at_load-_stext(r26) cmplwi cr0,r7,1/* kdump kernel ? - stay where we are */ bne 1f add r25