Hello Vivek, Andrew,
On Wed, 2011-09-14 at 14:29 -0400, Vivek Goyal wrote:
> On Wed, Sep 14, 2011 at 10:58:28AM +0200, Michael Holzheu wrote:
> > > Why not make this unconditional, for all architectures which support
> > > hugepages? ie:
> > >
> > > #ifdef HPAGE_SIZE
> > > #define KEXEC_CRASH_ME
Hello Vivek, Andrew, Martin
Here the version 3 patch series for the removal of page tables for the
crashkernel memory:
[1] kdump: Add infrastructure for unmapping crashkernel memory
[2] s390: Add architecture code for unmapping crashkernel memory
Changes to version 2: Use resource_size()
The pa
From: Michael Holzheu
This patch introduces a mechanism that allows architecture backends to
remove page tables for the crashkernel memory. This can protect the loaded
kdump kernel from being overwritten by broken kernel code. Two new
functions crash_map_reserved_pages() and crash_unmap_reserved
From: Michael Holzheu
This patch implements the crash_map_pages() function for s390.
KEXEC_CRASH_MEM_ALIGN is set to HPAGE_SIZE, in order to support
kernel mappings that use large pages. We also use HPAGE_SIZE alignment
for CONFIG_HUGETLB_PAGE=n in order to have the same 1 MiB alignment on
all s3
kdump saves the first 640kB physical memory in some backup region. The
question of mine is how to find the backup region from vmcore.
First let me explain why I have such question.
Fujitsu has sadump, Stand Alone Dump, which runs independently of
kernel logic, and the generated vmcore contains a
Add PHYSICAL_START kernel configuration parameter to set the address at
which the kernel should be loaded.
It has been observed on an sh7757lcr that simply modifying MEMORY_START
does not achieve this goal for 32bit sh. This is due to MEMORY_OFFSET in
arch/sh/kernel/vmlinux.lds.S bot being based o
Previously virt_to_phys() assumed that physical memory always started
at address 0. This is not always the case.
Tested on an sh7757lcr (32bit system) whose only System RAM region is
4000-4eff
Signed-off-by: Simon Horman
---
kexec/arch/sh/kexec-sh.c | 10 +-
1 files changed, 9
> I assume this is 512M?
Yes, 512M.
> It appears to have allocated a segment at this address. Can you try adding
> debug statements to exec to see the contents of this segment? I suspect kexec
> is loading nothing since it does not have an ELF header to load for the
> uImage case.
I added co
2011/9/15 Dennis Flynn :
>
>> I assume this is 512M?
> Yes, 512M.
>
>> It appears to have allocated a segment at this address. Can you try adding
>> debug statements to exec to see the contents of this segment? I suspect
>> kexec is loading nothing since it does not have an ELF header to load for
On Thu, Sep 15, 2011 at 11:13 AM, Maxim Uvarov wrote:
> 2011/9/15 Dennis Flynn :
>>
>>> I assume this is 512M?
>> Yes, 512M.
>>
>>> It appears to have allocated a segment at this address. Can you try adding
>>> debug statements to exec to see the contents of this segment? I suspect
>>> kexec is
On Fri, Sep 09, 2011 at 12:27:00PM +0200, Michael Holzheu wrote:
> From: Michael Holzheu
>
> Currently the vmcoreinfo note is only initialized in case of kdump. On s390
> it is possible to create kernel dumps with other dump mechanisms than kdump
> (e.g. via hypervisor dump or stand-alone dump to
This copy really don't need to do at the very second before the kernel
would crash.
Signed-off-by: Lei Wen
---
arch/arm/kernel/machine_kexec.c | 30 +++---
1 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel
On Thu, Sep 15, 2011 at 10:32:09PM -0700, Lei Wen wrote:
> This copy really don't need to do at the very second before the kernel
> would crash.
>
> Signed-off-by: Lei Wen
This seems reasonable to me.
Acked-by: Simon Horman
___
kexec mailing list
ke
13 matches
Mail list logo
