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
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
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
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.
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
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
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
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
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]
---
-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
.
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
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
(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
-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
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
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
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
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
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
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
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
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
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
23 matches
Mail list logo