On Fri, Mar 16, 2012 at 11:02:16AM +0800, Dave Young wrote:
> crashkernel reservation need know the total memory size. Current get_total_mem
> simply use max_pfn - min_low_pfn. It is wrong because it will including
> memory holes in the middle.
>
> Especially for kvm guest with memory > 0xe000
crashkernel reservation need know the total memory size. Current get_total_mem
simply use max_pfn - min_low_pfn. It is wrong because it will including
memory holes in the middle.
Especially for kvm guest with memory > 0xe000, there's below in qemu code:
qemu split memory as below:
if (ram_
Don,
Thank you.
I understand.
Seiji
> -Original Message-
> From: Don Zickus [mailto:dzic...@redhat.com]
> Sent: Thursday, March 15, 2012 5:34 PM
> To: Seiji Aguchi
> Cc: x...@kernel.org; LKML; kexec-list; Eric W. Biederman; Vivek Goyal
> Subject: Re: [PATCH] x86, kdump: No need to disabl
On Thu, Mar 15, 2012 at 05:16:50PM -0400, Seiji Aguchi wrote:
> Don,
>
> What do you think about following scenario?
> Disabling I/O APIC seems to be needed before booting kdump kernel.
This patch was for *booting* the second kernel. Kexec/kdump disables
interrupts before jumping into the second
Don,
What do you think about following scenario?
Disabling I/O APIC seems to be needed before booting kdump kernel.
Seiji
commit 1e75b31d638d5242ca8e9771dfdcbd28a5f041df
Author: Suresh Siddha
Date: Thu Aug 25 12:01:11 2011 -0700
x86, kdump, ioapic: Reset remote-IRR in clear_IO_APIC
On Wed, Feb 29, 2012 at 03:08:49PM -0500, Don Zickus wrote:
> A customer of ours noticed when their machine crashed, kdump did not
> work but hung instead. Using their firmware dumping solution they
> grabbed a vmcore and decoded the stacks on the cpus. What they
> noticed seemed to be a rare dea
