From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mx1.redhat.com ([209.132.183.28]) by bombadil.infradead.org with esmtp (Exim 4.69 #1 (Red Hat Linux)) id 1O0ESV-00023K-8b for kexec@lists.infradead.org; Fri, 09 Apr 2010 13:41:20 +0000 Date: Fri, 9 Apr 2010 09:41:11 -0400 From: Vivek Goyal Subject: Re: [PATCH] kexec: fix 64Gb limit on x86 w/ PAE Message-ID: <20100409134111.GA27573@redhat.com> References: <20100408164644.GB16868@hmsreliant.think-freely.org> <20100408223245.GA4795@verge.net.au> <20100409012439.GA2060@localhost.localdomain> <20100409014144.GA25947@verge.net.au> <20100409121749.GB16609@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20100409121749.GB16609@hmsreliant.think-freely.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: kexec-bounces@lists.infradead.org Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: Neil Horman Cc: anderson@redhat.com, Simon Horman , kexec@lists.infradead.org On Fri, Apr 09, 2010 at 08:17:49AM -0400, Neil Horman wrote: > Version 2, with Simons consistency fixes and cleanups > > Fix up x86 kexec to exclude memory on i686 kernels beyond 64GB limit > > We found a problem recently on x86 systems. If a 32 bit PAE enabled system > contains more then 64GB of physical ram, the kernel will truncate the max_pfn > value to 64GB. Unfortunately it still leaves all the physical memory regions > present in /proc/iomem. Since kexec builds its elf headers based on > /proc/iomem the elf headers indicate the size of memory is larger than what the > kernel is willing to address. The result is that, during a copy of > /proc/vmcore, a read will return -EFAULT when the requested offset is beyond the > 64GB range, leaving the seemingly truncated vmcore useless, as the elf headers > indicate memory beyond what the file contains. > > The fix for it is pretty straightforward, just ensure that, when on x86 systems, > we don't record any entries in the memory_range array that cross the 64Gb mark. > This keeps us in line with the kernel and lets the copy finish sucessfully, > providing a workable core > > Tested successfully by myself > Originally-authored-by: Dave Anderson > Signed-off-by: Neil Horman > > > crashdump-x86.c | 15 +++++++++++++++ > 1 file changed, 15 insertions(+) > > diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c > index 9d37442..9d35b3e 100644 > --- a/kexec/arch/i386/crashdump-x86.c > +++ b/kexec/arch/i386/crashdump-x86.c > @@ -34,6 +34,12 @@ > #include "crashdump-x86.h" > #include > > +/* > + * This defines the the last address that we can support access to > + * with a PAE enabled kernel > + */ > +#define 64G_LIMIT 0xfffffffff > + > extern struct arch_options_t arch_options; > > /* Forward Declaration. */ > @@ -114,6 +120,15 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges, > if (end <= 0x0009ffff) > continue; > > + /* > + * Exclude any segments starting at or beyond 64GB, and > + * restrict any segments from ending at or beyond 64GB. > + */ > + if (start > 64GB_LIMIT) > + continue; > + if (end > 64GB_LIMIT) > + end = 64GB_LIMIT; > + Looks good to me. Acked-by: Vivek Goyal Vivek > crash_memory_range[memory_ranges].start = start; > crash_memory_range[memory_ranges].end = end; > crash_memory_range[memory_ranges].type = type; _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec