* [PATCH] kexec: fix 64Gb limit on x86 w/ PAE @ 2010-04-08 16:46 Neil Horman 2010-04-08 22:32 ` Simon Horman 0 siblings, 1 reply; 8+ messages in thread From: Neil Horman @ 2010-04-08 16:46 UTC (permalink / raw) To: kexec; +Cc: horms, anderson, vgoyal 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 <anderson@redhat.com> Signed-off-by: Neil Horman <nhorman@tuxdriver.com> diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c index 9d37442..85879a9 100644 --- a/kexec/arch/i386/crashdump-x86.c +++ b/kexec/arch/i386/crashdump-x86.c @@ -114,6 +114,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 >= 0x1000000000) + continue; + if (end >= 0x1000000000) + end = 0xfffffffff; + 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 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] kexec: fix 64Gb limit on x86 w/ PAE 2010-04-08 16:46 [PATCH] kexec: fix 64Gb limit on x86 w/ PAE Neil Horman @ 2010-04-08 22:32 ` Simon Horman 2010-04-09 1:24 ` Neil Horman 0 siblings, 1 reply; 8+ messages in thread From: Simon Horman @ 2010-04-08 22:32 UTC (permalink / raw) To: Neil Horman; +Cc: anderson, kexec, vgoyal On Thu, Apr 08, 2010 at 12:46:44PM -0400, Neil Horman wrote: > 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 Hi Neil, This seems reasonable to me. > Tested successfully by myself > Originally-authored-by: Dave Anderson <anderson@redhat.com> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com> > > diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c > index 9d37442..85879a9 100644 > --- a/kexec/arch/i386/crashdump-x86.c > +++ b/kexec/arch/i386/crashdump-x86.c > @@ -114,6 +114,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 >= 0x1000000000) > + continue; > + if (end >= 0x1000000000) > + end = 0xfffffffff; > + Nit picking... Might it be better to use 0xfffffffff (or 0x1000000000) consistently? if (start > 0xfffffffff) continue; if (end > 0xfffffffff) end = 0xfffffffff; Or even make 0xfffffffff (or 0x1000000000) a #define ? > 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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] kexec: fix 64Gb limit on x86 w/ PAE 2010-04-08 22:32 ` Simon Horman @ 2010-04-09 1:24 ` Neil Horman 2010-04-09 1:41 ` Simon Horman 0 siblings, 1 reply; 8+ messages in thread From: Neil Horman @ 2010-04-09 1:24 UTC (permalink / raw) To: Simon Horman; +Cc: anderson, kexec, vgoyal On Fri, Apr 09, 2010 at 08:32:48AM +1000, Simon Horman wrote: > On Thu, Apr 08, 2010 at 12:46:44PM -0400, Neil Horman wrote: > > 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 > > Hi Neil, > > This seems reasonable to me. > > > Tested successfully by myself > > Originally-authored-by: Dave Anderson <anderson@redhat.com> > > Signed-off-by: Neil Horman <nhorman@tuxdriver.com> > > > > diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c > > index 9d37442..85879a9 100644 > > --- a/kexec/arch/i386/crashdump-x86.c > > +++ b/kexec/arch/i386/crashdump-x86.c > > @@ -114,6 +114,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 >= 0x1000000000) > > + continue; > > + if (end >= 0x1000000000) > > + end = 0xfffffffff; > > + > > Nit picking... > > Might it be better to use 0xfffffffff (or 0x1000000000) consistently? > > if (start > 0xfffffffff) > continue; > if (end > 0xfffffffff) > end = 0xfffffffff; > Not sure what you mean by consistent here? It seems we are using it consistently in this patch. Or are you referring to updating the function as a whole? > Or even make 0xfffffffff (or 0x1000000000) a #define ? Yeah, that makes sense. If you can clarify your above point on consistency, I can repost. thanks Neil > > > 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 > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] kexec: fix 64Gb limit on x86 w/ PAE 2010-04-09 1:24 ` Neil Horman @ 2010-04-09 1:41 ` Simon Horman 2010-04-09 11:05 ` Neil Horman 2010-04-09 12:17 ` Neil Horman 0 siblings, 2 replies; 8+ messages in thread From: Simon Horman @ 2010-04-09 1:41 UTC (permalink / raw) To: Neil Horman; +Cc: anderson, kexec, vgoyal On Thu, Apr 08, 2010 at 09:24:39PM -0400, Neil Horman wrote: > On Fri, Apr 09, 2010 at 08:32:48AM +1000, Simon Horman wrote: > > On Thu, Apr 08, 2010 at 12:46:44PM -0400, Neil Horman wrote: > > > 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 > > > > Hi Neil, > > > > This seems reasonable to me. > > > > > Tested successfully by myself > > > Originally-authored-by: Dave Anderson <anderson@redhat.com> > > > Signed-off-by: Neil Horman <nhorman@tuxdriver.com> > > > > > > diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c > > > index 9d37442..85879a9 100644 > > > --- a/kexec/arch/i386/crashdump-x86.c > > > +++ b/kexec/arch/i386/crashdump-x86.c > > > @@ -114,6 +114,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 >= 0x1000000000) > > > + continue; > > > + if (end >= 0x1000000000) > > > + end = 0xfffffffff; > > > + > > > > Nit picking... > > > > Might it be better to use 0xfffffffff (or 0x1000000000) consistently? > > > > if (start > 0xfffffffff) > > continue; > > if (end > 0xfffffffff) > > end = 0xfffffffff; > > > Not sure what you mean by consistent here? It seems we are using it > consistently in this patch. Or are you referring to updating the function as a > whole? Sorry, yes they are consistent. And I believe the code you posted is correct. What I meant was that as 0xfffffffff + 1 = 0x1000000000, the code could either only use 0xfffffffff or only use 0x1000000000. Which seems to make things slightly more obvious when reading the code. > > Or even make 0xfffffffff (or 0x1000000000) a #define ? > Yeah, that makes sense. If you can clarify your above point on consistency, I > can repost. > > thanks > Neil > > > > > > 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 > > _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] kexec: fix 64Gb limit on x86 w/ PAE 2010-04-09 1:41 ` Simon Horman @ 2010-04-09 11:05 ` Neil Horman 2010-04-09 12:17 ` Neil Horman 1 sibling, 0 replies; 8+ messages in thread From: Neil Horman @ 2010-04-09 11:05 UTC (permalink / raw) To: Simon Horman; +Cc: kexec, anderson, vgoyal, Neil Horman On Fri, Apr 09, 2010 at 11:41:47AM +1000, Simon Horman wrote: > On Thu, Apr 08, 2010 at 09:24:39PM -0400, Neil Horman wrote: > > On Fri, Apr 09, 2010 at 08:32:48AM +1000, Simon Horman wrote: > > > On Thu, Apr 08, 2010 at 12:46:44PM -0400, Neil Horman wrote: > > > > 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 > > > > > > Hi Neil, > > > > > > This seems reasonable to me. > > > > > > > Tested successfully by myself > > > > Originally-authored-by: Dave Anderson <anderson@redhat.com> > > > > Signed-off-by: Neil Horman <nhorman@tuxdriver.com> > > > > > > > > diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c > > > > index 9d37442..85879a9 100644 > > > > --- a/kexec/arch/i386/crashdump-x86.c > > > > +++ b/kexec/arch/i386/crashdump-x86.c > > > > @@ -114,6 +114,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 >= 0x1000000000) > > > > + continue; > > > > + if (end >= 0x1000000000) > > > > + end = 0xfffffffff; > > > > + > > > > > > Nit picking... > > > > > > Might it be better to use 0xfffffffff (or 0x1000000000) consistently? > > > > > > if (start > 0xfffffffff) > > > continue; > > > if (end > 0xfffffffff) > > > end = 0xfffffffff; > > > > > Not sure what you mean by consistent here? It seems we are using it > > consistently in this patch. Or are you referring to updating the function as a > > whole? > > Sorry, yes they are consistent. And I believe the code you posted is correct. > > What I meant was that as 0xfffffffff + 1 = 0x1000000000, > the code could either only use 0xfffffffff or only use 0x1000000000. > Which seems to make things slightly more obvious when reading the code. > Ah, ok. yeah, I'm fine with that. I'll bump the value, change the comparison to >=, macrotize the constant and repost. Thanks! Neil > > > Or even make 0xfffffffff (or 0x1000000000) a #define ? > > Yeah, that makes sense. If you can clarify your above point on consistency, I > > can repost. > > > > thanks > > Neil > > > > > > > > > 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 > > > > > _______________________________________________ > kexec mailing list > kexec@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/kexec _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] kexec: fix 64Gb limit on x86 w/ PAE 2010-04-09 1:41 ` Simon Horman 2010-04-09 11:05 ` Neil Horman @ 2010-04-09 12:17 ` Neil Horman 2010-04-09 13:41 ` Vivek Goyal 1 sibling, 1 reply; 8+ messages in thread From: Neil Horman @ 2010-04-09 12:17 UTC (permalink / raw) To: Simon Horman; +Cc: anderson, kexec, vgoyal 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 <anderson@redhat.com> Signed-off-by: Neil Horman <nhorman@tuxdriver.com> 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 <x86/x86-linux.h> +/* + * 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; + 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 ^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH] kexec: fix 64Gb limit on x86 w/ PAE 2010-04-09 12:17 ` Neil Horman @ 2010-04-09 13:41 ` Vivek Goyal 2010-04-12 5:58 ` Simon Horman 0 siblings, 1 reply; 8+ messages in thread From: Vivek Goyal @ 2010-04-09 13:41 UTC (permalink / raw) To: Neil Horman; +Cc: anderson, Simon Horman, kexec 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 <anderson@redhat.com> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com> > > > 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 <x86/x86-linux.h> > > +/* > + * 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 <vgoyal@redhat.com> 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] kexec: fix 64Gb limit on x86 w/ PAE 2010-04-09 13:41 ` Vivek Goyal @ 2010-04-12 5:58 ` Simon Horman 0 siblings, 0 replies; 8+ messages in thread From: Simon Horman @ 2010-04-12 5:58 UTC (permalink / raw) To: Vivek Goyal; +Cc: anderson, kexec, Neil Horman On Fri, Apr 09, 2010 at 09:41:11AM -0400, Vivek Goyal wrote: > 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 <anderson@redhat.com> > > Signed-off-by: Neil Horman <nhorman@tuxdriver.com> > > > > > > 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 <x86/x86-linux.h> > > > > +/* > > + * 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 <vgoyal@redhat.com> Thanks Neil. Thanks Vivek. Thanks Dave. Applied :-) _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2010-04-12 5:58 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-04-08 16:46 [PATCH] kexec: fix 64Gb limit on x86 w/ PAE Neil Horman 2010-04-08 22:32 ` Simon Horman 2010-04-09 1:24 ` Neil Horman 2010-04-09 1:41 ` Simon Horman 2010-04-09 11:05 ` Neil Horman 2010-04-09 12:17 ` Neil Horman 2010-04-09 13:41 ` Vivek Goyal 2010-04-12 5:58 ` Simon Horman
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.