From bhe at redhat.com  Wed Nov  1 00:21:07 2017
From: bhe at redhat.com (Baoquan He)
Date: Wed, 1 Nov 2017 15:21:07 +0800
Subject: [PATCH 3/3] kdump: round up the total memory size to 128M for
 crashkernel reservation
In-Reply-To: <20171024060944.GB8585@dhcp-128-65.nay.redhat.com>
References: <20171024053901.813846011@redhat.com> <20171024055722.GG27757@x1>
 <20171024060944.GB8585@dhcp-128-65.nay.redhat.com>
Message-ID: <20171101072107.GH12058@x1>

On 10/24/17 at 02:09pm, Dave Young wrote:
> Hi Baoquan,
> 
> On 10/24/17 at 01:57pm, Baoquan He wrote:
> > Hi Dave,
> > 
> > On 10/24/17 at 01:31pm, Dave Young wrote:
> > > The total memory size we get in kernel is usually slightly less than 2G with a
> > > 2G memory module machine. The main reason is bios/firmware reserve some area
> > > it will not export all memory as usable to Linux.
> > > 
> > > 2G memory X86 kvm guest test result of the total_mem value:
> > > UEFI boot with ovmf: 0x7ef10000
> > > Legacy boot kvm guest: 0x7ff7cc00
> > > 
> > > An option is to use dmi/smbios to get physical memory size, but it's not
> > > reliable as well. According to Prarit hardware vendors sometimes screw this up.
> > > Thus we choose to round up total size to 128M to workaround this problem.
> > > This is a best effort workaround, will improve it when we have better way
> > > in the future. 
> > 
> > Thanks for this posting. While I don't get the point of this patch. So
> > firmware take piece of memory, then why we need to count it into the
> > total memory which we want to calculate a crashkernel memory based on.
> > 
> > Not counting that, is there anyting incorrect?
> 
> Yes, considering crashkernel=1G-2G:128M,  if we have a 1G memory
> machine, we get total size 1023M from firmware then it will not fall
> into 1G-2G thus no memory reserved.  User will never know that, it is
> hard to let user to know the exact total value we get in kernel..

OK, got it. Thanks.

Then I have no objection to this. See what other reviewers will say.

Thanks
Baoquan


> > 
> > > 
> > > Signed-off-by: Dave Young <dyoung at redhat.com>
> > > ---
> > >  kernel/crash_core.c |   17 +++++++++++++----
> > >  1 file changed, 13 insertions(+), 4 deletions(-)
> > > 
> > > --- linux.orig/kernel/crash_core.c
> > > +++ linux/kernel/crash_core.c
> > > @@ -42,6 +42,15 @@ static int __init parse_crashkernel_mem(
> > >  {
> > >  	char *cur = cmdline, *tmp;
> > >  	bool infinite_end = false;
> > > +	unsigned long long total_mem = system_ram;
> > > +
> > > +	/*
> > > +	 * Firmware usually reserves some memory regions for it's own use.
> > > +	 * so we get less than actual system memory size.
> > > +	 * We workaround this by round up the total size to 128M which is
> > > +	 * enough for most test cases.
> > > +	 */
> > > +	total_mem = roundup(total_mem, 0x8000000);
> > >  
> > >  	/* for each entry of the comma-separated list */
> > >  	do {
> > > @@ -86,13 +95,13 @@ static int __init parse_crashkernel_mem(
> > >  			return -EINVAL;
> > >  		}
> > >  		cur = tmp;
> > > -		if (size >= system_ram) {
> > > +		if (size >= total_mem) {
> > >  			pr_warn("crashkernel: invalid size\n");
> > >  			return -EINVAL;
> > >  		}
> > >  
> > >  		/* match ? */
> > > -		if (system_ram >= start && system_ram < end) {
> > > +		if (total_mem >= start && total_mem < end) {
> > >  			*crash_size = size;
> > >  			if (end == ULLONG_MAX)
> > >  				infinite_end = true;
> > > @@ -126,9 +135,9 @@ static int __init parse_crashkernel_mem(
> > >  				pr_warn("Memory reservation scale order expected after '^'\n");
> > >  				return -EINVAL;
> > >  			}
> > > -			size = (system_ram - *crash_size) >> shift;
> > > +			size = (total_mem - *crash_size) >> shift;
> > >  			size = *crash_size + roundup(size, 1ULL << 20);
> > > -			if (size < system_ram)
> > > +			if (size < total_mem)
> > >  				*crash_size = size;
> > >  			cur = tmp;
> > >  		} else
> > > 
> > > 
> 
> Thanks
> Dave


From horms at verge.net.au  Wed Nov  1 01:08:09 2017
From: horms at verge.net.au (Simon Horman)
Date: Wed, 1 Nov 2017 09:08:09 +0100
Subject: [ANNOUNCE] kexec-tools v2.0.16 preparation
Message-ID: <20171101080809.qidfwrtzvbzavbqj@verge.net.au>

Hi all,

I am planning to release kexec-tools v2.0.16 in the next two weeks.

The normal cadence would have seen it released around the time of the v4.13
kernel. I apologise that once again things have slipped and the plan is no
to release around the time of the v4.14 kernel.

I would like to ask interested parties to send any patches they would like
included in v2.0.16 within one week so that I can make an rc release.

For reference the patches queued up since v2.0.15 are as follows:

c06753313db7 kexec-tools: mips: Use proper page_offset for OCTEON CPUs.
77e769bd1d1f kexec-tools: mips: Merge adjacent memory ranges.
508c7d45e270 kexec-tools: mips: Try to include bss in kernel vmcore file.
552bfbfc00ee kexec-tools: mips: Don't set lowmem_limit to 2G for 64-bit systems.
69431282f075 kexec-tools: ppc64: fix leak while checking for coherent device memory
aec4d0f7a250 kexec-tools: ppc64: avoid adding coherent memory regions to crash memory ranges
21eb397a5fc9 kexec-tools: powerpc: fix command line overflow error
47478ea66d43 kexec-tools: ppc64: fix how RMA top is deduced
161dd0f4f8a8 kexec-tools 2.0.15.git


From horms at verge.net.au  Wed Nov  1 01:10:25 2017
From: horms at verge.net.au (Simon Horman)
Date: Wed, 1 Nov 2017 09:10:25 +0100
Subject: [PATCH 1/2] ARM: cleanup initrd and dtb handing
In-Reply-To: <20171023100547.GA5431@n2100.armlinux.org.uk>
References: <20171023100547.GA5431@n2100.armlinux.org.uk>
Message-ID: <20171101081024.4n7ikghrpgrzogmc@verge.net.au>

On Mon, Oct 23, 2017 at 11:05:48AM +0100, Russell King wrote:
> There is no difference in the way the initrd is handled between an
> ATAG-based kernel and a DTB-based kernel.  Therefore, this should be
> handled identically in both cases.
> 
> Rearrange the code to achieve this.
> 
> Signed-off-by: Russell King <rmk at armlinux.org.uk>

Thanks, applied.


From horms at verge.net.au  Wed Nov  1 01:10:36 2017
From: horms at verge.net.au (Simon Horman)
Date: Wed, 1 Nov 2017 09:10:36 +0100
Subject: [PATCH 2/2] ARM: read kernel size from zImage
In-Reply-To: <20171023100834.GA5462@n2100.armlinux.org.uk>
References: <20171023100834.GA5462@n2100.armlinux.org.uk>
Message-ID: <20171101081036.57ahx2bymugl5s37@verge.net.au>

On Mon, Oct 23, 2017 at 11:08:34AM +0100, Russell King wrote:
> Read the new extension data which tells the boot agent about the
> requirements for booting the kernel image, such as how much RAM
> will be consumed by the kernel through decompression and booting.
> This is necessary to control the placement of the DTB and
> compressed RAM disk to avoid these objects being corrupted.
> 
> Tested-by: Tony Lindgren <tony at atomide.com>
> Signed-off-by: Russell King <rmk at armlinux.org.uk>

Thanks, applied.


From rmk at armlinux.org.uk  Wed Nov  1 03:56:36 2017
From: rmk at armlinux.org.uk (Russell King)
Date: Wed, 1 Nov 2017 10:56:36 +0000
Subject: [PATCH 2/2] ARM: read kernel size from zImage
In-Reply-To: <20171101081036.57ahx2bymugl5s37@verge.net.au>
References: <20171023100834.GA5462@n2100.armlinux.org.uk>
 <20171101081036.57ahx2bymugl5s37@verge.net.au>
Message-ID: <20171101105636.GG5019@flint.armlinux.org.uk>

On Wed, Nov 01, 2017 at 09:10:36AM +0100, Simon Horman wrote:
> On Mon, Oct 23, 2017 at 11:08:34AM +0100, Russell King wrote:
> > Read the new extension data which tells the boot agent about the
> > requirements for booting the kernel image, such as how much RAM
> > will be consumed by the kernel through decompression and booting.
> > This is necessary to control the placement of the DTB and
> > compressed RAM disk to avoid these objects being corrupted.
> > 
> > Tested-by: Tony Lindgren <tony at atomide.com>
> > Signed-off-by: Russell King <rmk at armlinux.org.uk>
> 
> Thanks, applied.

Thanks, since I rebased my tree, I've realised that wasn't quite the
patch I intended, but it'll do for now.

Building the latest tree gives me a new warning:

gcc -g -O2 -fno-strict-aliasing -Wall -Wstrict-prototypes -I./include -I./util_lib/include -Iinclude/ -I./kexec/libfdt -D_FILE_OFFSET_BITS=64 -I./kexec/arch/arm/include  -c -MD -o kexec/kexec.o kexec/kexec.c
kexec/kexec.c: In function ?print_crashkernel_region_size?:
kexec/kexec.c:1232:9: warning: format ?%lu? expects argument of type ?long unsigned int?, but argument 2 has type ?uint64_t {aka long long unsigned int}? [-Wformat=]
  printf("%lu\n", (start != end) ? (end - start + 1) : 0UL);
         ^

caused by:

commit 76b31203222a9833f424e98a134603c2f840c82b
Author: Daniel Kiper <daniel.kiper at oracle.com>
Date:   Fri Feb 17 16:47:25 2017 -0600

    kexec: Add option to get crash kernel region size

On 32-bit architectures, "%lu" expects an unsigned long, but uint64_t is
an unsigned long long.  On 64-bit architectures, "%lu" also expects an
unsigned long, but uint64_t is unsigned long, so there's no warning.

The problem for ARM here is that a 64-bit value is passed as an
even-odd register pair, so for the above printf, that would be r2, r3.
However, "%lu" will expect the value in the first register following
the format pointer, that being r1.  So we end up printing garbage here.

Either we use "%llu" and cast the value to an unsigned long long
(needlessly widening on 64-bit arches), or "%lu" and cast to unsigned
long (truncating) or we need a definition of the format to be used for
uint64_t types (tends to be messy.)

-- 
Russell King


From dyoung at redhat.com  Thu Nov  2 19:46:22 2017
From: dyoung at redhat.com (Dave Young)
Date: Fri, 3 Nov 2017 10:46:22 +0800
Subject: [PATCH 3/3 update] kdump: round up the total memory size to 128M for
 crashkernel reservation
In-Reply-To: <20171024053901.813846011@redhat.com>
References: <20171024053901.813846011@redhat.com>
Message-ID: <20171103024622.GA5584@dhcp-128-65.nay.redhat.com>

The total memory size we get in kernel is usually slightly less than 2G with a
2G memory module machine. The main reason is bios/firmware reserve some area
it will not export all memory as usable to Linux.

2G memory X86 kvm guest test result of the total_mem value:
UEFI boot with ovmf: 0x7ef10000
Legacy boot kvm guest: 0x7ff7cc00
This is also a problem on arm64 UEFI booted system according to my test.

Thus for example crashkernel=1G-2G:128M,  if we have a 1G memory
machine, we get total size 1023M from firmware then it will not fall
into 1G-2G thus no memory reserved.

An option is to use dmi/smbios to get physical memory size, but it's not
reliable as well. According to Prarit hardware vendors sometimes screw this up.
Thus round up total size to 128M to workaround this problem.

Signed-off-by: Dave Young <dyoung at redhat.com>
---
Changes from previous version of 3/3:
1. improve changelog: add examples why this is a problem (comment from
   Baoquan He)
2. change to use SZ_128M (comment from Bhupesh Sharma)

 kernel/crash_core.c |   18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

--- linux-x86.orig/kernel/crash_core.c
+++ linux-x86/kernel/crash_core.c
@@ -9,6 +9,7 @@
 #include <linux/crash_core.h>
 #include <linux/utsname.h>
 #include <linux/vmalloc.h>
+#include <linux/sizes.h>
 
 #include <asm/page.h>
 #include <asm/sections.h>
@@ -42,6 +43,15 @@ static int __init parse_crashkernel_mem(
 {
 	char *cur = cmdline, *tmp;
 	bool infinite_end = false;
+	unsigned long long total_mem = system_ram;
+
+	/*
+	 * Firmware usually reserves some memory regions for it's own use.
+	 * so we get less than actual system memory size.
+	 * We workaround this by round up the total size to 128M which is
+	 * enough for most test cases.
+	 */
+	total_mem = roundup(total_mem, SZ_128M);
 
 	/* for each entry of the comma-separated list */
 	do {
@@ -86,13 +96,13 @@ static int __init parse_crashkernel_mem(
 			return -EINVAL;
 		}
 		cur = tmp;
-		if (size >= system_ram) {
+		if (size >= total_mem) {
 			pr_warn("crashkernel: invalid size\n");
 			return -EINVAL;
 		}
 
 		/* match ? */
-		if (system_ram >= start && system_ram < end) {
+		if (total_mem >= start && total_mem < end) {
 			*crash_size = size;
 			if (end == ULLONG_MAX)
 				infinite_end = true;
@@ -126,9 +136,9 @@ static int __init parse_crashkernel_mem(
 				pr_warn("Memory reservation scale order expected after '^'\n");
 				return -EINVAL;
 			}
-			size = (system_ram - *crash_size) >> shift;
+			size = (total_mem - *crash_size) >> shift;
 			size = *crash_size + roundup(size, 1ULL << 20);
-			if (size < system_ram)
+			if (size < total_mem)
 				*crash_size = size;
 			cur = tmp;
 		} else


From jbohac at suse.cz  Fri Nov  3 10:28:22 2017
From: jbohac at suse.cz (Jiri Bohac)
Date: Fri, 3 Nov 2017 18:28:22 +0100
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
Message-ID: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>

On machines where the GART aperture is mapped over physical RAM
/proc/vmcore contains the remapped range and reading it may
cause hangs or reboots. This range needs to be excluded from /proc/vmcore.

This has originally been implemented by commit dd5f726076cc ("kexec:
support for kexec on panic using new system call").

The implementation relied on the GART code adding an iomem_resource for
this range called "GART", as implemented by commit 56dd669a138c ("[PATCH]
Insert GART region into resource map")

However, inserting the iomem_resource from the early GART code caused
resource conflicts with some AGP drivers (bko#72201), which got avoided by
reverting the patch in commit 707d4eefbdb3 ("Revert [PATCH] Insert GART
region into resource map"). This revert introduced the /proc/vmcore bug.

With the "GART" iomem_resource removed, the defunct code in crash.c has
been removed by commit f296f2634920 ("x86/kexec: Remove walk_iomem_res()
call with GART type")

The patch below stores the location of the GART region in two variables
(named gart_stolen_ram_start and gart_stolen_ram_end) and reverts/adapts
parts of f296f2634920 to exclude the region from /proc/vmcore.

Passing the information via an iomem_resource (or by reserving the range
in the e820, which would propagate into an iomem_resource) would
reintroduce bko#72201.

Signed-off-by: Jiri Bohac <jbohac at suse.cz>
Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map")

diff --git a/arch/x86/include/asm/gart.h b/arch/x86/include/asm/gart.h
index 1d268098ac2e..324a0a19d166 100644
--- a/arch/x86/include/asm/gart.h
+++ b/arch/x86/include/asm/gart.h
@@ -2,6 +2,7 @@
 #define _ASM_X86_GART_H
 
 #include <asm/e820/api.h>
+#include <linux/pci.h>
 
 extern void set_up_gart_resume(u32, u32);
 
@@ -33,6 +34,8 @@ extern int fix_aperture;
 extern int gart_iommu_aperture;
 extern int gart_iommu_aperture_allowed;
 extern int gart_iommu_aperture_disabled;
+extern u32 gart_stolen_ram_start;
+extern u32 gart_stolen_ram_end;
 
 extern void early_gart_iommu_check(void);
 extern int gart_iommu_init(void);
@@ -43,6 +46,8 @@ extern int gart_iommu_hole_init(void);
 #define gart_iommu_aperture            0
 #define gart_iommu_aperture_allowed    0
 #define gart_iommu_aperture_disabled   1
+#define gart_stolen_ram_start	       0
+#define gart_stolen_ram_end	       0
 
 static inline void early_gart_iommu_check(void)
 {
diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
index ef2859f9fcce..bc9a9b5b88e3 100644
--- a/arch/x86/kernel/aperture_64.c
+++ b/arch/x86/kernel/aperture_64.c
@@ -49,6 +49,8 @@
 int gart_iommu_aperture;
 int gart_iommu_aperture_disabled __initdata;
 int gart_iommu_aperture_allowed __initdata;
+u32 gart_stolen_ram_start;
+u32 gart_stolen_ram_end;
 
 int fallback_aper_order __initdata = 1; /* 64MB */
 int fallback_aper_force __initdata;
@@ -87,6 +89,9 @@ static u32 __init allocate_aperture(void)
 	register_nosave_region(addr >> PAGE_SHIFT,
 			       (addr+aper_size) >> PAGE_SHIFT);
 
+	gart_stolen_ram_start = (u32)addr;
+	gart_stolen_ram_end = (u32)addr + aper_size - 1;
+
 	return (u32)addr;
 }
 
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 44404e2307bb..ce065d72656d 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -37,6 +37,7 @@
 #include <asm/reboot.h>
 #include <asm/virtext.h>
 #include <asm/intel_pt.h>
+#include <asm/gart.h>
 
 /* Alignment required for elf header segment */
 #define ELF_CORE_HEADER_ALIGN   4096
@@ -58,7 +59,7 @@ struct crash_elf_data {
 	struct kimage *image;
 	/*
 	 * Total number of ram ranges we have after various adjustments for
-	 * crash reserved region, etc.
+	 * GART, crash reserved region etc.
 	 */
 	unsigned int max_nr_ranges;
 
@@ -217,7 +218,6 @@ static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
 	return 0;
 }
 
-
 /* Gather all the required information to prepare elf headers for ram regions */
 static void fill_up_crash_elf_data(struct crash_elf_data *ced,
 				   struct kimage *image)
@@ -231,6 +231,15 @@ static void fill_up_crash_elf_data(struct crash_elf_data *ced,
 
 	ced->max_nr_ranges = nr_ranges;
 
+	/*
+	 * We don't create ELF headers for GART aperture as an attempt
+	 * to dump this memory in second kernel leads to hang/crash.
+	 * If gart aperture is mapped over RAM, one needs to exclude that region
+	 * and that requires an extra phdr.
+	 */
+	if (gart_stolen_ram_start)
+		ced->max_nr_ranges++;
+
 	/* Exclusion of crash region could split memory ranges */
 	ced->max_nr_ranges++;
 
@@ -339,6 +348,14 @@ static int elf_header_exclude_ranges(struct crash_elf_data *ced,
 			return ret;
 	}
 
+	/* Exclude GART region */
+	if (gart_stolen_ram_start) {
+		ret = exclude_mem_range(cmem, gart_stolen_ram_start,
+					gart_stolen_ram_end);
+		if (ret)
+			return ret;
+	}
+
 	return ret;
 }
 
-- 
Jiri Bohac <jbohac at suse.cz>
SUSE Labs, Prague, Czechia



From bhe at redhat.com  Sun Nov  5 18:41:43 2017
From: bhe at redhat.com (Baoquan He)
Date: Mon, 6 Nov 2017 10:41:43 +0800
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
Message-ID: <20171106024143.GA3669@x1>

Hi Jiri,

On 11/03/17 at 06:28pm, Jiri Bohac wrote:
> On machines where the GART aperture is mapped over physical RAM
> /proc/vmcore contains the remapped range and reading it may
> cause hangs or reboots. This range needs to be excluded from /proc/vmcore.
> 
> This has originally been implemented by commit dd5f726076cc ("kexec:
> support for kexec on panic using new system call").
> 
> The implementation relied on the GART code adding an iomem_resource for
> this range called "GART", as implemented by commit 56dd669a138c ("[PATCH]
> Insert GART region into resource map")
> 
> However, inserting the iomem_resource from the early GART code caused
> resource conflicts with some AGP drivers (bko#72201), which got avoided by
> reverting the patch in commit 707d4eefbdb3 ("Revert [PATCH] Insert GART
> region into resource map"). This revert introduced the /proc/vmcore bug.
> 
> With the "GART" iomem_resource removed, the defunct code in crash.c has
> been removed by commit f296f2634920 ("x86/kexec: Remove walk_iomem_res()
> call with GART type")

Is this reproduced on a machine with GART existing and passing test with
this patch applied? Do you have a /proc/iomem printing about the machine
you are testing on?

If this patch works, then I am wondering how we shold deal with the old
way in which no '-s' is specified. Since no GART information is exported
to /proc/iomem.

Do we have a way to pick GART region away from iomem_resource to not let
the aperture seen from /proc/iomem?

Thanks
Baoquan

> 
> The patch below stores the location of the GART region in two variables
> (named gart_stolen_ram_start and gart_stolen_ram_end) and reverts/adapts
> parts of f296f2634920 to exclude the region from /proc/vmcore.
> 
> Passing the information via an iomem_resource (or by reserving the range
> in the e820, which would propagate into an iomem_resource) would
> reintroduce bko#72201.
> 
> Signed-off-by: Jiri Bohac <jbohac at suse.cz>
> Fixes: 707d4eefbdb3 ("Revert [PATCH] Insert GART region into resource map")
> 
> diff --git a/arch/x86/include/asm/gart.h b/arch/x86/include/asm/gart.h
> index 1d268098ac2e..324a0a19d166 100644
> --- a/arch/x86/include/asm/gart.h
> +++ b/arch/x86/include/asm/gart.h
> @@ -2,6 +2,7 @@
>  #define _ASM_X86_GART_H
>  
>  #include <asm/e820/api.h>
> +#include <linux/pci.h>
>  
>  extern void set_up_gart_resume(u32, u32);
>  
> @@ -33,6 +34,8 @@ extern int fix_aperture;
>  extern int gart_iommu_aperture;
>  extern int gart_iommu_aperture_allowed;
>  extern int gart_iommu_aperture_disabled;
> +extern u32 gart_stolen_ram_start;
> +extern u32 gart_stolen_ram_end;
>  
>  extern void early_gart_iommu_check(void);
>  extern int gart_iommu_init(void);
> @@ -43,6 +46,8 @@ extern int gart_iommu_hole_init(void);
>  #define gart_iommu_aperture            0
>  #define gart_iommu_aperture_allowed    0
>  #define gart_iommu_aperture_disabled   1
> +#define gart_stolen_ram_start	       0
> +#define gart_stolen_ram_end	       0
>  
>  static inline void early_gart_iommu_check(void)
>  {
> diff --git a/arch/x86/kernel/aperture_64.c b/arch/x86/kernel/aperture_64.c
> index ef2859f9fcce..bc9a9b5b88e3 100644
> --- a/arch/x86/kernel/aperture_64.c
> +++ b/arch/x86/kernel/aperture_64.c
> @@ -49,6 +49,8 @@
>  int gart_iommu_aperture;
>  int gart_iommu_aperture_disabled __initdata;
>  int gart_iommu_aperture_allowed __initdata;
> +u32 gart_stolen_ram_start;
> +u32 gart_stolen_ram_end;
>  
>  int fallback_aper_order __initdata = 1; /* 64MB */
>  int fallback_aper_force __initdata;
> @@ -87,6 +89,9 @@ static u32 __init allocate_aperture(void)
>  	register_nosave_region(addr >> PAGE_SHIFT,
>  			       (addr+aper_size) >> PAGE_SHIFT);
>  
> +	gart_stolen_ram_start = (u32)addr;
> +	gart_stolen_ram_end = (u32)addr + aper_size - 1;
> +
>  	return (u32)addr;
>  }
>  
> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 44404e2307bb..ce065d72656d 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c
> @@ -37,6 +37,7 @@
>  #include <asm/reboot.h>
>  #include <asm/virtext.h>
>  #include <asm/intel_pt.h>
> +#include <asm/gart.h>
>  
>  /* Alignment required for elf header segment */
>  #define ELF_CORE_HEADER_ALIGN   4096
> @@ -58,7 +59,7 @@ struct crash_elf_data {
>  	struct kimage *image;
>  	/*
>  	 * Total number of ram ranges we have after various adjustments for
> -	 * crash reserved region, etc.
> +	 * GART, crash reserved region etc.
>  	 */
>  	unsigned int max_nr_ranges;
>  
> @@ -217,7 +218,6 @@ static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
>  	return 0;
>  }
>  
> -
>  /* Gather all the required information to prepare elf headers for ram regions */
>  static void fill_up_crash_elf_data(struct crash_elf_data *ced,
>  				   struct kimage *image)
> @@ -231,6 +231,15 @@ static void fill_up_crash_elf_data(struct crash_elf_data *ced,
>  
>  	ced->max_nr_ranges = nr_ranges;
>  
> +	/*
> +	 * We don't create ELF headers for GART aperture as an attempt
> +	 * to dump this memory in second kernel leads to hang/crash.
> +	 * If gart aperture is mapped over RAM, one needs to exclude that region
> +	 * and that requires an extra phdr.
> +	 */
> +	if (gart_stolen_ram_start)
> +		ced->max_nr_ranges++;
> +
>  	/* Exclusion of crash region could split memory ranges */
>  	ced->max_nr_ranges++;
>  
> @@ -339,6 +348,14 @@ static int elf_header_exclude_ranges(struct crash_elf_data *ced,
>  			return ret;
>  	}
>  
> +	/* Exclude GART region */
> +	if (gart_stolen_ram_start) {
> +		ret = exclude_mem_range(cmem, gart_stolen_ram_start,
> +					gart_stolen_ram_end);
> +		if (ret)
> +			return ret;
> +	}
> +
>  	return ret;
>  }
>  
> -- 
> Jiri Bohac <jbohac at suse.cz>
> SUSE Labs, Prague, Czechia
> 


From bhe at redhat.com  Mon Nov  6 01:27:29 2017
From: bhe at redhat.com (Baoquan He)
Date: Mon, 6 Nov 2017 17:27:29 +0800
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
 <20171106024143.GA3669@x1>
 <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
Message-ID: <20171106092729.GB3669@x1>

Hi Jiri,

Thanks for providing these information.

On 11/06/17 at 10:01am, Jiri Bohac wrote:
> Hi Baoquan,
> 
> 	[    0.000000] memblock_reserve: [0x00000000b8000000-0x00000000bbffffff] gart_iommu_hole_init+0x396/0x4b6
> 	[    0.000000] AGP: Mapping aperture over RAM [mem 0xb8000000-0xbbffffff] (65536KB)
> ^^^^^

> /proc/iomem:
> 	00000000-00000fff : Reserved
> 	00001000-0009d7ff : System RAM
> 	0009d800-0009ffff : Reserved
> 	000a0000-000bffff : PCI Bus 0000:00
> 	000c0000-000cafff : PCI Bus 0000:00
> 	  000c0000-000cafff : Video ROM
> 	000cb000-000ccfff : Adapter ROM
> 	000ce000-000fffff : Reserved
> 	  000f0000-000fffff : System ROM
> 	00100000-c7e7ffff : System RAM
> 	  0b000000-0b792eb5 : Kernel code
> 	  0b792eb6-0bd5d47f : Kernel data
> 	  0c274000-0c3c8fff : Kernel bss
> 	  b7000000-c6ffffff : Crash kernel

It's weird, gart aperture located in crashkernel region? Or we need
reserve the low crashkernel memory for gart aperture usage, Just like
swiotlb?

Sorry, I am not familiar with gart.

Thanks
Baoquan


> 	c7e80000-c7e8afff : ACPI Tables
> 	c7e8b000-c7e8cfff : ACPI Non-volatile Storage
> 	c7e8d000-c7ffffff : Reserved
> 	c8000000-ce0fffff : PCI Bus 0000:00
> 	  c8000000-c80003ff : IOAPIC 1
> 	  c8014000-c80143ff : 0000:00:11.0
> 	    c8014000-c80143ff : ahci
> 	  c8014400-c80144ff : 0000:00:12.2
> 	    c8014400-c80144ff : ehci_hcd
 
 


From jbohac at suse.cz  Mon Nov  6 01:56:38 2017
From: jbohac at suse.cz (Jiri Bohac)
Date: Mon, 6 Nov 2017 10:56:38 +0100
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171106092729.GB3669@x1>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
 <20171106024143.GA3669@x1>
 <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
 <20171106092729.GB3669@x1>
Message-ID: <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz>

On Mon, Nov 06, 2017 at 05:27:29PM +0800, Baoquan He wrote:
> > 	00100000-c7e7ffff : System RAM
> > 	  0b000000-0b792eb5 : Kernel code
> > 	  0b792eb6-0bd5d47f : Kernel data
> > 	  0c274000-0c3c8fff : Kernel bss
> > 	  b7000000-c6ffffff : Crash kernel
> 
> It's weird, gart aperture located in crashkernel region? 

Ooops! I sent you a /proc/iomem from a different boot than the
dmesg, whith different crashkernel= commandline. Sorry, this is
the correct /proc/iomem:


	00000000-00000fff : Reserved
	00001000-0009d7ff : System RAM
	0009d800-0009ffff : Reserved
	000a0000-000bffff : PCI Bus 0000:00
	000c0000-000cafff : PCI Bus 0000:00
	  000c0000-000cafff : Video ROM
	000cb000-000ccfff : Adapter ROM
	000ce000-000fffff : Reserved
	  000f0000-000fffff : System ROM
	00100000-c7e7ffff : System RAM
	  c3000000-c77fffff : Crash kernel
	c7e80000-c7e8afff : ACPI Tables
	c7e8b000-c7e8cfff : ACPI Non-volatile Storage
	c7e8d000-c7ffffff : Reserved
	c8000000-ce0fffff : PCI Bus 0000:00
	  c8000000-c80003ff : IOAPIC 1
	  c8014000-c80143ff : 0000:00:11.0
	    c8014000-c80143ff : ahci
	  c8014400-c80144ff : 0000:00:12.2
	    c8014400-c80144ff : ehci_hcd
	  c8014800-c80148ff : 0000:00:13.2
	    c8014800-c80148ff : ehci_hcd
	  c8015000-c8015fff : 0000:00:12.0
	    c8015000-c8015fff : ohci_hcd
	  c8016000-c8016fff : 0000:00:12.1
	    c8016000-c8016fff : ohci_hcd
	  c8017000-c8017fff : 0000:00:13.0
	    c8017000-c8017fff : ohci_hcd
	  c8018000-c8018fff : 0000:00:13.1
	    c8018000-c8018fff : ohci_hcd
	  c8019000-c8019fff : 0000:00:14.5
	    c8019000-c8019fff : ohci_hcd
	  ca000000-cdffffff : PCI Bus 0000:01
	    ca000000-cbffffff : 0000:01:00.0
	      ca000000-cbffffff : bnx2
	    cc000000-cdffffff : 0000:01:00.1
	      cc000000-cdffffff : bnx2
	  ce000000-ce0fffff : PCI Bus 0000:02
	    ce000000-ce00ffff : 0000:02:06.0
	d0000000-d7ffffff : PCI Bus 0000:00
	  d0000000-d7ffffff : PCI Bus 0000:02
	    d0000000-d7ffffff : 0000:02:06.0
	e0000000-efffffff : Reserved
	  e0000000-efffffff : pnp 00:00
	    e0000000-e02fffff : PCI MMCONFIG 0000 [bus 00-02]
	fec00000-fec0ffff : Reserved
	  fec00000-fec003ff : IOAPIC 0
	fec10000-fec1001f : pnp 00:05
	fed00000-fed003ff : HPET 2
	  fed00000-fed003ff : PNP0103:00
	fed40000-fed45000 : PCI Bus 0000:00
	fee00000-fee00fff : Local APIC
	  fee00000-fee00fff : Reserved
	    fee00000-fee00fff : pnp 00:00
	fff00000-ffffffff : Reserved
	  fff00000-ffffffff : pnp 00:05
	100000000-837ffffff : System RAM
	  4df000000-4df792eb5 : Kernel code
	  4df792eb6-4dfd5d47f : Kernel data
	  4e0274000-4e03c8fff : Kernel bss
	  831000000-8374fffff : Crash kernel

Sorry for the confusion!

-- 
Jiri Bohac <jbohac at suse.cz>
SUSE Labs, Prague, Czechia



From jeffm at suse.com  Mon Nov  6 18:52:01 2017
From: jeffm at suse.com (Jeff Mahoney)
Date: Mon, 6 Nov 2017 21:52:01 -0500
Subject: [PATCH] handle renamed init_level4_pgt -> init_top_pgt
Message-ID: <2f878100-945b-e0b1-ef6d-d51f4071edd6@suse.com>

Linux 4.13 renamed init_level4_pgt to init_top_pgt in preparation for
introducing 5-level page tables.  This patch follows the rename if
the lookup for init_level4_pgt fails.  It also checks to see if
5-level page tables are enabled and bails if it discovers they are.

Signed-off-by: Jeff Mahoney <jeffm at suse.com>
---
 arch/x86_64.c  | 24 +++++++++++++++++++++---
 makedumpfile.c |  6 ++++++
 makedumpfile.h |  2 ++
 3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/arch/x86_64.c b/arch/x86_64.c
index 08dd6b2..9b09035 100644
--- a/arch/x86_64.c
+++ b/arch/x86_64.c
@@ -259,16 +259,26 @@ vtop4_x86_64(unsigned long vaddr)
 {
 	unsigned long page_dir, pml4, pgd_paddr, pgd_pte, pmd_paddr, pmd_pte;
 	unsigned long pte_paddr, pte;
+	unsigned long init_level4_pgt;
 
-	if (SYMBOL(init_level4_pgt) == NOT_FOUND_SYMBOL) {
+	if (SYMBOL(init_level4_pgt) != NOT_FOUND_SYMBOL)
+		init_level4_pgt = SYMBOL(init_level4_pgt);
+	else if (SYMBOL(init_top_pgt) != NOT_FOUND_SYMBOL)
+		init_level4_pgt = SYMBOL(init_top_pgt);
+	else {
 		ERRMSG("Can't get the symbol of init_level4_pgt.\n");
 		return NOT_PADDR;
 	}
 
+	if (SYMBOL(level4_kernel_pgt) != NOT_FOUND_SYMBOL) {
+		ERRMSG("Kernel is built with 5-level page tables\n");
+		return NOT_PADDR;
+	}
+
 	/*
 	 * Get PGD.
 	 */
-	page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + info->phys_base;
+	page_dir = init_level4_pgt - __START_KERNEL_map + info->phys_base;
 	if (is_xen_memory()) {
 		page_dir = ptom_xen(page_dir);
 		if (page_dir == NOT_PADDR)
@@ -549,8 +559,16 @@ find_vmemmap_x86_64()
 	struct vmap_pfns *vmapp, *vmaphead = NULL, *cur, *tail;
 
 	init_level4_pgt = SYMBOL(init_level4_pgt);
+	if (init_level4_pgt == NOT_FOUND_SYMBOL)
+		init_level4_pgt = SYMBOL(init_top_pgt);
+
 	if (init_level4_pgt == NOT_FOUND_SYMBOL) {
-		ERRMSG("init_level4_pgt not found\n");
+		ERRMSG("init_level4_pgt/init_top_pgt not found\n");
+		return FAILED;
+	}
+
+	if (SYMBOL(level4_kernel_pgt) != NOT_FOUND_SYMBOL) {
+		ERRMSG("kernel is configured for 5-level page tables\n");
 		return FAILED;
 	}
 	pagestructsize = size_table.page;
diff --git a/makedumpfile.c b/makedumpfile.c
index f85003a..6e5ec34 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -1486,6 +1486,8 @@ get_symbol_info(void)
 	SYMBOL_INIT(_stext, "_stext");
 	SYMBOL_INIT(swapper_pg_dir, "swapper_pg_dir");
 	SYMBOL_INIT(init_level4_pgt, "init_level4_pgt");
+	SYMBOL_INIT(level4_kernel_pgt, "level4_kernel_pgt");
+	SYMBOL_INIT(init_top_pgt, "init_top_pgt");
 	SYMBOL_INIT(vmlist, "vmlist");
 	SYMBOL_INIT(vmap_area_list, "vmap_area_list");
 	SYMBOL_INIT(node_online_map, "node_online_map");
@@ -2105,6 +2107,8 @@ write_vmcoreinfo_data(void)
 	WRITE_SYMBOL("_stext", _stext);
 	WRITE_SYMBOL("swapper_pg_dir", swapper_pg_dir);
 	WRITE_SYMBOL("init_level4_pgt", init_level4_pgt);
+	WRITE_SYMBOL("level4_kernel_pgt", level4_kernel_pgt);
+	WRITE_SYMBOL("init_top_pgt", init_top_pgt);
 	WRITE_SYMBOL("vmlist", vmlist);
 	WRITE_SYMBOL("vmap_area_list", vmap_area_list);
 	WRITE_SYMBOL("node_online_map", node_online_map);
@@ -2500,6 +2504,8 @@ read_vmcoreinfo(void)
 	READ_SYMBOL("_stext", _stext);
 	READ_SYMBOL("swapper_pg_dir", swapper_pg_dir);
 	READ_SYMBOL("init_level4_pgt", init_level4_pgt);
+	READ_SYMBOL("level4_kernel_pgt", level4_kernel_pgt);
+	READ_SYMBOL("init_top_pgt", init_top_pgt);
 	READ_SYMBOL("vmlist", vmlist);
 	READ_SYMBOL("vmap_area_list", vmap_area_list);
 	READ_SYMBOL("node_online_map", node_online_map);
diff --git a/makedumpfile.h b/makedumpfile.h
index 8a05794..9357e47 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -1517,6 +1517,8 @@ struct symbol_table {
 	unsigned long long	_stext;
 	unsigned long long	swapper_pg_dir;
 	unsigned long long	init_level4_pgt;
+	unsigned long long	level4_kernel_pgt;
+	unsigned long long	init_top_pgt;
 	unsigned long long	vmlist;
 	unsigned long long	vmap_area_list;
 	unsigned long long	phys_base;


-- 
Jeff Mahoney
SUSE Labs


From ats-kumagai at wm.jp.nec.com  Tue Nov  7 02:20:02 2017
From: ats-kumagai at wm.jp.nec.com (Atsushi Kumagai)
Date: Tue, 7 Nov 2017 10:20:02 +0000
Subject: [PATCH] handle renamed init_level4_pgt -> init_top_pgt
Message-ID: <0910DD04CBD6DE4193FCF86B9C00BE9701F22E63@BPXM01GP.gisp.nec.co.jp>

>Linux 4.13 renamed init_level4_pgt to init_top_pgt in preparation for
>introducing 5-level page tables.  This patch follows the rename if
>the lookup for init_level4_pgt fails.  It also checks to see if
>5-level page tables are enabled and bails if it discovers they are.

Thanks Jeff, but could you rebase it on the current devel branch ?
vtop4 for x86_64 was modified in the commit below:

commit 8c89727155f4994b4e75a659e28e5eff16ff6cbc
Author: Takao Indoh <indou.takao at jp.fujitsu.com>
Date:   Thu Oct 26 20:32:54 2017 +0900

    [PATCH v3 2/4] Introduce vtop4_x86_64_pagetable

Regards,
Atsushi Kumagai

>Signed-off-by: Jeff Mahoney <jeffm at suse.com>
>---
> arch/x86_64.c  | 24 +++++++++++++++++++++---
> makedumpfile.c |  6 ++++++
> makedumpfile.h |  2 ++
> 3 files changed, 29 insertions(+), 3 deletions(-)
>
>diff --git a/arch/x86_64.c b/arch/x86_64.c
>index 08dd6b2..9b09035 100644
>--- a/arch/x86_64.c
>+++ b/arch/x86_64.c
>@@ -259,16 +259,26 @@ vtop4_x86_64(unsigned long vaddr)
> {
> 	unsigned long page_dir, pml4, pgd_paddr, pgd_pte, pmd_paddr, pmd_pte;
> 	unsigned long pte_paddr, pte;
>+	unsigned long init_level4_pgt;
>
>-	if (SYMBOL(init_level4_pgt) == NOT_FOUND_SYMBOL) {
>+	if (SYMBOL(init_level4_pgt) != NOT_FOUND_SYMBOL)
>+		init_level4_pgt = SYMBOL(init_level4_pgt);
>+	else if (SYMBOL(init_top_pgt) != NOT_FOUND_SYMBOL)
>+		init_level4_pgt = SYMBOL(init_top_pgt);
>+	else {
> 		ERRMSG("Can't get the symbol of init_level4_pgt.\n");
> 		return NOT_PADDR;
> 	}
>
>+	if (SYMBOL(level4_kernel_pgt) != NOT_FOUND_SYMBOL) {
>+		ERRMSG("Kernel is built with 5-level page tables\n");
>+		return NOT_PADDR;
>+	}
>+
> 	/*
> 	 * Get PGD.
> 	 */
>-	page_dir = SYMBOL(init_level4_pgt) - __START_KERNEL_map + info->phys_base;
>+	page_dir = init_level4_pgt - __START_KERNEL_map + info->phys_base;
> 	if (is_xen_memory()) {
> 		page_dir = ptom_xen(page_dir);
> 		if (page_dir == NOT_PADDR)
>@@ -549,8 +559,16 @@ find_vmemmap_x86_64()
> 	struct vmap_pfns *vmapp, *vmaphead = NULL, *cur, *tail;
>
> 	init_level4_pgt = SYMBOL(init_level4_pgt);
>+	if (init_level4_pgt == NOT_FOUND_SYMBOL)
>+		init_level4_pgt = SYMBOL(init_top_pgt);
>+
> 	if (init_level4_pgt == NOT_FOUND_SYMBOL) {
>-		ERRMSG("init_level4_pgt not found\n");
>+		ERRMSG("init_level4_pgt/init_top_pgt not found\n");
>+		return FAILED;
>+	}
>+
>+	if (SYMBOL(level4_kernel_pgt) != NOT_FOUND_SYMBOL) {
>+		ERRMSG("kernel is configured for 5-level page tables\n");
> 		return FAILED;
> 	}
> 	pagestructsize = size_table.page;
>diff --git a/makedumpfile.c b/makedumpfile.c
>index f85003a..6e5ec34 100644
>--- a/makedumpfile.c
>+++ b/makedumpfile.c
>@@ -1486,6 +1486,8 @@ get_symbol_info(void)
> 	SYMBOL_INIT(_stext, "_stext");
> 	SYMBOL_INIT(swapper_pg_dir, "swapper_pg_dir");
> 	SYMBOL_INIT(init_level4_pgt, "init_level4_pgt");
>+	SYMBOL_INIT(level4_kernel_pgt, "level4_kernel_pgt");
>+	SYMBOL_INIT(init_top_pgt, "init_top_pgt");
> 	SYMBOL_INIT(vmlist, "vmlist");
> 	SYMBOL_INIT(vmap_area_list, "vmap_area_list");
> 	SYMBOL_INIT(node_online_map, "node_online_map");
>@@ -2105,6 +2107,8 @@ write_vmcoreinfo_data(void)
> 	WRITE_SYMBOL("_stext", _stext);
> 	WRITE_SYMBOL("swapper_pg_dir", swapper_pg_dir);
> 	WRITE_SYMBOL("init_level4_pgt", init_level4_pgt);
>+	WRITE_SYMBOL("level4_kernel_pgt", level4_kernel_pgt);
>+	WRITE_SYMBOL("init_top_pgt", init_top_pgt);
> 	WRITE_SYMBOL("vmlist", vmlist);
> 	WRITE_SYMBOL("vmap_area_list", vmap_area_list);
> 	WRITE_SYMBOL("node_online_map", node_online_map);
>@@ -2500,6 +2504,8 @@ read_vmcoreinfo(void)
> 	READ_SYMBOL("_stext", _stext);
> 	READ_SYMBOL("swapper_pg_dir", swapper_pg_dir);
> 	READ_SYMBOL("init_level4_pgt", init_level4_pgt);
>+	READ_SYMBOL("level4_kernel_pgt", level4_kernel_pgt);
>+	READ_SYMBOL("init_top_pgt", init_top_pgt);
> 	READ_SYMBOL("vmlist", vmlist);
> 	READ_SYMBOL("vmap_area_list", vmap_area_list);
> 	READ_SYMBOL("node_online_map", node_online_map);
>diff --git a/makedumpfile.h b/makedumpfile.h
>index 8a05794..9357e47 100644
>--- a/makedumpfile.h
>+++ b/makedumpfile.h
>@@ -1517,6 +1517,8 @@ struct symbol_table {
> 	unsigned long long	_stext;
> 	unsigned long long	swapper_pg_dir;
> 	unsigned long long	init_level4_pgt;
>+	unsigned long long	level4_kernel_pgt;
>+	unsigned long long	init_top_pgt;
> 	unsigned long long	vmlist;
> 	unsigned long long	vmap_area_list;
> 	unsigned long long	phys_base;
>
>
>--
>Jeff Mahoney
>SUSE Labs




From bhe at redhat.com  Tue Nov  7 03:39:56 2017
From: bhe at redhat.com (Baoquan He)
Date: Tue, 7 Nov 2017 19:39:56 +0800
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
 <20171106024143.GA3669@x1>
 <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
 <20171106092729.GB3669@x1>
 <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz>
Message-ID: <20171107113956.GC3669@x1>

On 11/06/17 at 10:56am, Jiri Bohac wrote:
> On Mon, Nov 06, 2017 at 05:27:29PM +0800, Baoquan He wrote:
> > > 	00100000-c7e7ffff : System RAM
> > > 	  0b000000-0b792eb5 : Kernel code
> > > 	  0b792eb6-0bd5d47f : Kernel data
> > > 	  0c274000-0c3c8fff : Kernel bss
> > > 	  b7000000-c6ffffff : Crash kernel
> > 
> > It's weird, gart aperture located in crashkernel region? 
> 
> Ooops! I sent you a /proc/iomem from a different boot than the
> dmesg, whith different crashkernel= commandline. Sorry, this is
> the correct /proc/iomem:
> 
> 
> 	00000000-00000fff : Reserved
> 	00001000-0009d7ff : System RAM
> 	0009d800-0009ffff : Reserved
> 	000a0000-000bffff : PCI Bus 0000:00
> 	000c0000-000cafff : PCI Bus 0000:00
> 	  000c0000-000cafff : Video ROM
> 	000cb000-000ccfff : Adapter ROM
> 	000ce000-000fffff : Reserved
> 	  000f0000-000fffff : System ROM
> 	00100000-c7e7ffff : System RAM

AGP: Mapping aperture over RAM [mem 0xb8000000-0xbbffffff] (65536KB)

So on this system, gart is located inside 00100000-c7e7ffff : System
RAM.

I saw you defined the variable as xx_stolen_xx, does it mean that the
memory region where aperture located will be stolen from memory domain?
I am wondering if it will cause error when access this region from direct
mapping since allocate_aperture() is called in pci_iommu_alloc(), while
in setup_arch() we have built the direct mapping for all system
ram. Did I miss anything?

Anyway, if it should be excluded from crash memory region, can we dig it
away from /proc/iomem so that it's a hole in /proc/vmcore? Like this, we
don't worry about the user space kexec utility either. Could be I still
don't get it, may need to read the code of gart.

Thanks
Baoquan
> 	  c3000000-c77fffff : Crash kernel
> 	c7e80000-c7e8afff : ACPI Tables
> 	c7e8b000-c7e8cfff : ACPI Non-volatile Storage
> 	c7e8d000-c7ffffff : Reserved
> 	c8000000-ce0fffff : PCI Bus 0000:00
> 	  c8000000-c80003ff : IOAPIC 1
> 	  c8014000-c80143ff : 0000:00:11.0
> 	    c8014000-c80143ff : ahci
> 	  c8014400-c80144ff : 0000:00:12.2
> 	    c8014400-c80144ff : ehci_hcd
> 	  c8014800-c80148ff : 0000:00:13.2
> 	    c8014800-c80148ff : ehci_hcd
> 	  c8015000-c8015fff : 0000:00:12.0
> 	    c8015000-c8015fff : ohci_hcd
> 	  c8016000-c8016fff : 0000:00:12.1
> 	    c8016000-c8016fff : ohci_hcd
> 	  c8017000-c8017fff : 0000:00:13.0
> 	    c8017000-c8017fff : ohci_hcd
> 	  c8018000-c8018fff : 0000:00:13.1
> 	    c8018000-c8018fff : ohci_hcd
> 	  c8019000-c8019fff : 0000:00:14.5
> 	    c8019000-c8019fff : ohci_hcd
> 	  ca000000-cdffffff : PCI Bus 0000:01
> 	    ca000000-cbffffff : 0000:01:00.0
> 	      ca000000-cbffffff : bnx2
> 	    cc000000-cdffffff : 0000:01:00.1
> 	      cc000000-cdffffff : bnx2
> 	  ce000000-ce0fffff : PCI Bus 0000:02
> 	    ce000000-ce00ffff : 0000:02:06.0
> 	d0000000-d7ffffff : PCI Bus 0000:00
> 	  d0000000-d7ffffff : PCI Bus 0000:02
> 	    d0000000-d7ffffff : 0000:02:06.0
> 	e0000000-efffffff : Reserved
> 	  e0000000-efffffff : pnp 00:00
> 	    e0000000-e02fffff : PCI MMCONFIG 0000 [bus 00-02]
> 	fec00000-fec0ffff : Reserved
> 	  fec00000-fec003ff : IOAPIC 0
> 	fec10000-fec1001f : pnp 00:05
> 	fed00000-fed003ff : HPET 2
> 	  fed00000-fed003ff : PNP0103:00
> 	fed40000-fed45000 : PCI Bus 0000:00
> 	fee00000-fee00fff : Local APIC
> 	  fee00000-fee00fff : Reserved
> 	    fee00000-fee00fff : pnp 00:00
> 	fff00000-ffffffff : Reserved
> 	  fff00000-ffffffff : pnp 00:05
> 	100000000-837ffffff : System RAM
> 	  4df000000-4df792eb5 : Kernel code
> 	  4df792eb6-4dfd5d47f : Kernel data
> 	  4e0274000-4e03c8fff : Kernel bss
> 	  831000000-8374fffff : Crash kernel
> 
> Sorry for the confusion!
> 
> -- 
> Jiri Bohac <jbohac at suse.cz>
> SUSE Labs, Prague, Czechia
> 


From jbohac at suse.cz  Tue Nov  7 05:42:12 2017
From: jbohac at suse.cz (Jiri Bohac)
Date: Tue, 7 Nov 2017 14:42:12 +0100
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171107113956.GC3669@x1>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
 <20171106024143.GA3669@x1>
 <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
 <20171106092729.GB3669@x1>
 <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz>
 <20171107113956.GC3669@x1>
Message-ID: <20171107134212.tmjdt7rdailtbosa@dwarf.suse.cz>

On Tue, Nov 07, 2017 at 07:39:56PM +0800, Baoquan He wrote:
> I saw you defined the variable as xx_stolen_xx, does it mean that the
> memory region where aperture located will be stolen from memory domain?
> I am wondering if it will cause error when access this region from direct
> mapping since allocate_aperture() is called in pci_iommu_alloc(), while
> in setup_arch() we have built the direct mapping for all system
> ram. Did I miss anything?

yes, I believe accessing it through the direct mapping would
cause the error; but the range is allocated by the memblock
allocator and never given back, which effectively steals it from
any other use; The memory will never be given to any user by any
subsequent allocation, so nothing will access it.

> Anyway, if it should be excluded from crash memory region, can we dig it
> away from /proc/iomem so that it's a hole in /proc/vmcore? Like this, we

Not sure this would work. In bko#72201, marking the range as used
caused pci_claim_resource() to error out with -EBUSY after
request_resource_conflict() (the error message has changed in
29003be but the logic remains).

My (possibly wrong?) reading of pci_claim_resource() tells me
that leaving the range out of the map would cause it to error out
a little earlier with -EINVAL just after
pci_find_parent_resource().  I'd rather avoid such experiments in
fear of causing regressions similar to bko#72201. This particular
one remained unnoticed for 8 years. I can't possibly test all AGP
drivers :/ 
(So much for my justification of passing this to crash
independently of the iomem_resource/e820 infrastructure.)

> don't worry about the user space kexec utility either. 

What's the problem with the userspace kexec? The bug is in
reading /proc/vmcore by makedumpfile. kexec would only operate
within the preallocated crashkernel area, right?

Regards,

-- 
Jiri Bohac <jbohac at suse.cz>
SUSE Labs, Prague, Czechia



From jbohac at suse.cz  Tue Nov  7 07:34:28 2017
From: jbohac at suse.cz (Jiri Bohac)
Date: Tue, 7 Nov 2017 16:34:28 +0100
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171107134212.tmjdt7rdailtbosa@dwarf.suse.cz>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
 <20171106024143.GA3669@x1>
 <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
 <20171106092729.GB3669@x1>
 <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz>
 <20171107113956.GC3669@x1>
 <20171107134212.tmjdt7rdailtbosa@dwarf.suse.cz>
Message-ID: <20171107153428.ex27nwkvelhm2nm7@dwarf.suse.cz>

On Tue, Nov 07, 2017 at 02:42:12PM +0100, Jiri Bohac wrote:
> On Tue, Nov 07, 2017 at 07:39:56PM +0800, Baoquan He wrote:
> > don't worry about the user space kexec utility either. 
> 
> What's the problem with the userspace kexec? The bug is in
> reading /proc/vmcore by makedumpfile. kexec would only operate
> within the preallocated crashkernel area, right?

right, I see it (without -s the kexec userspace creates the ELF header
later used the second kernel for /proc/vmcore).

No idea how to fix that nicely...

-- 
Jiri Bohac <jbohac at suse.cz>
SUSE Labs, Prague, Czechia



From xiyou.wangcong at gmail.com  Tue Nov  7 16:03:31 2017
From: xiyou.wangcong at gmail.com (Cong Wang)
Date: Tue,  7 Nov 2017 16:03:31 -0800
Subject: [Patch resend] vmcore-dmesg: avoid allocating large memory chunk for
 log buf
Message-ID: <20171108000331.8640-1-xiyou.wangcong@gmail.com>

In kdump kernel, we got:

    Saving vmcore-dmesg.txt
    Failed to malloc 67108864 bytes for the logbuf: Cannot allocate memory

Apparently 64M is too luxury for a kdump kernel which only has 128M
in total.

We can avoid allocating such a large memory chunk, instead just allocate
a smaller chunk inside the loop each time.

Verify the result by comparing the vmcore-dmesg output with and without
this patch.

Cc: Simon Horman <horms at verge.net.au>
Reviewed-by: Dave Young <dyoung at redhat.com>
Reviewed-by: Pratyush Anand <panand at redhat.com>
Signed-off-by: Cong Wang <xiyou.wangcong at gmail.com>
---
 vmcore-dmesg/vmcore-dmesg.c | 99 ++++++++++++++++++---------------------------
 1 file changed, 39 insertions(+), 60 deletions(-)

diff --git a/vmcore-dmesg/vmcore-dmesg.c b/vmcore-dmesg/vmcore-dmesg.c
index a8f56df..e340ef4 100644
--- a/vmcore-dmesg/vmcore-dmesg.c
+++ b/vmcore-dmesg/vmcore-dmesg.c
@@ -565,53 +565,12 @@ static inline uint64_t struct_val_u64(char *ptr, unsigned int offset)
 	return(file64_to_cpu(*(uint64_t *)(ptr + offset)));
 }
 
-/* human readable text of the record */
-static char *log_text(char *msg)
-{
-	return msg + log_sz;
-}
-
-/* get record by index; idx must point to valid msg */
-static char *log_from_idx(char *log_buf, uint32_t idx)
-{
-	char *msg = log_buf + idx;
-
-	/*
-	 * A length == 0 record is the end of buffer marker. Wrap around and
-	 * read the message at the start of the buffer.
-	 */
-	if (!struct_val_u16(msg, log_offset_len))
-		return log_buf;
-	return msg;
-}
-
-/* get next record; idx must point to valid msg */
-static uint32_t log_next(char *log_buf, uint32_t idx)
-{
-	char *msg = log_buf + idx;
-	uint16_t len;
-
-	/* length == 0 indicates the end of the buffer; wrap */
-	/*
-	 * A length == 0 record is the end of buffer marker. Wrap around and
-	 * read the message at the start of the buffer as *this* one, and
-	 * return the one after that.
-	 */
-	len = struct_val_u16(msg, log_offset_len);
-	if (!len) {
-		msg = log_buf;
-		return struct_val_u16(msg, log_offset_len);
-	}
-	return idx + len;
-}
-
 /* Read headers of log records and dump accordingly */
 static void dump_dmesg_structured(int fd)
 {
 #define OUT_BUF_SIZE	4096
 	uint64_t log_buf, log_buf_offset, ts_nsec;
 	uint32_t log_first_idx, log_next_idx, current_idx, len = 0, i;
-	int log_buf_len;
 	char *buf, out_buf[OUT_BUF_SIZE];
 	ssize_t ret;
 	char *msg;
@@ -659,34 +618,33 @@ static void dump_dmesg_structured(int fd)
 	}
 
 	log_buf = read_file_pointer(fd, vaddr_to_offset(log_buf_vaddr));
-	log_buf_len = read_file_s32(fd, vaddr_to_offset(log_buf_len_vaddr));
 
 	log_first_idx = read_file_u32(fd, vaddr_to_offset(log_first_idx_vaddr));
 	log_next_idx = read_file_u32(fd, vaddr_to_offset(log_next_idx_vaddr));
 
 	log_buf_offset = vaddr_to_offset(log_buf);
 
-	buf = calloc(1, log_buf_len);
+	buf = calloc(1, log_sz);
 	if (!buf) {
-		fprintf(stderr, "Failed to malloc %d bytes for the logbuf:"
-				" %s\n", log_buf_len, strerror(errno));
+		fprintf(stderr, "Failed to malloc %" PRId64 " bytes for the log:"
+				" %s\n", log_sz, strerror(errno));
 		exit(64);
 	}
 
-	ret = pread(fd, buf, log_buf_len, log_buf_offset);
-	if (ret != log_buf_len) {
-		fprintf(stderr, "Failed to read log buffer of size %d bytes:"
-			" %s\n", log_buf_len, strerror(errno));
-		exit(65);
-	}
-
 	/* Parse records and write out data at standard output */
 
 	current_idx = log_first_idx;
 	len = 0;
 	while (current_idx != log_next_idx) {
-		msg = log_from_idx(buf, current_idx);
-		ts_nsec = struct_val_u64(msg, log_offset_ts_nsec);
+		uint16_t loglen;
+
+		ret = pread(fd, buf, log_sz, log_buf_offset + current_idx);
+		if (ret != log_sz) {
+			fprintf(stderr, "Failed to read log of size %" PRId64 " bytes:"
+				" %s\n", log_sz, strerror(errno));
+			exit(65);
+		}
+		ts_nsec = struct_val_u64(buf, log_offset_ts_nsec);
 		imaxdiv_sec = imaxdiv(ts_nsec, 1000000000);
 		imaxdiv_usec = imaxdiv(imaxdiv_sec.rem, 1000);
 
@@ -695,9 +653,22 @@ static void dump_dmesg_structured(int fd)
 			(long long unsigned int)imaxdiv_usec.quot);
 
 		/* escape non-printable characters */
-		text_len = struct_val_u16(msg, log_offset_text_len);
+		text_len = struct_val_u16(buf, log_offset_text_len);
+		msg = calloc(1, text_len);
+		if (!msg) {
+			fprintf(stderr, "Failed to malloc %u bytes for log text:"
+				" %s\n", text_len, strerror(errno));
+			exit(64);
+		}
+
+		ret = pread(fd, msg, text_len, log_buf_offset + current_idx + log_sz);
+		if (ret != text_len) {
+			fprintf(stderr, "Failed to read log text of size %u bytes:"
+				" %s\n", text_len, strerror(errno));
+			exit(65);
+		}
 		for (i = 0; i < text_len; i++) {
-			unsigned char c = log_text(msg)[i];
+			unsigned char c = msg[i];
 
 			if (!isprint(c) && !isspace(c))
 				len += sprintf(out_buf + len, "\\x%02x", c);
@@ -711,11 +682,19 @@ static void dump_dmesg_structured(int fd)
 		}
 
 		out_buf[len++] = '\n';
-
-		/* Move to next record */
-		current_idx = log_next(buf, current_idx);
+		free(msg);
+		/*
+		 * A length == 0 record is the end of buffer marker. Wrap around
+		 * and read the message at the start of the buffer.
+		 */
+		loglen = struct_val_u16(buf, log_offset_len);
+		if (!loglen)
+			current_idx = log_first_idx;
+		else
+			/* Move to next record */
+			current_idx += loglen;
 	}
-
+	free(buf);
 	if (len)
 		write_to_stdout(out_buf, len);
 }
-- 
2.13.0



From horms at verge.net.au  Wed Nov  8 17:20:16 2017
From: horms at verge.net.au (Simon Horman)
Date: Thu, 9 Nov 2017 10:20:16 +0900
Subject: [Patch resend] vmcore-dmesg: avoid allocating large memory chunk
 for log buf
In-Reply-To: <20171108000331.8640-1-xiyou.wangcong@gmail.com>
References: <20171108000331.8640-1-xiyou.wangcong@gmail.com>
Message-ID: <20171109012016.ltq4wgddj6vvjvkk@verge.net.au>

On Tue, Nov 07, 2017 at 04:03:31PM -0800, Cong Wang wrote:
> In kdump kernel, we got:
> 
>     Saving vmcore-dmesg.txt
>     Failed to malloc 67108864 bytes for the logbuf: Cannot allocate memory
> 
> Apparently 64M is too luxury for a kdump kernel which only has 128M
> in total.
> 
> We can avoid allocating such a large memory chunk, instead just allocate
> a smaller chunk inside the loop each time.
> 
> Verify the result by comparing the vmcore-dmesg output with and without
> this patch.
> 
> Cc: Simon Horman <horms at verge.net.au>
> Reviewed-by: Dave Young <dyoung at redhat.com>
> Reviewed-by: Pratyush Anand <panand at redhat.com>
> Signed-off-by: Cong Wang <xiyou.wangcong at gmail.com>

Thanks, applied.


From horms at verge.net.au  Wed Nov  8 17:30:26 2017
From: horms at verge.net.au (Simon Horman)
Date: Thu, 9 Nov 2017 10:30:26 +0900
Subject: [ANNOUNCE] kexec-tools 2.0.16-rc1
Message-ID: <20171109013025.wp2g2wqs5fdddum6@verge.net.au>

Hi all,

I am happy to announce the release of kexec-tools 2.0.16-rc1.

This is an incremental feature pre-release.

So long as no serious problems arise I intend to release kexec-tools 2.0.16
in a weeks time. Testing of 2.0.16-rc1 would be greatly appreciated.

I do not have any outstanding changes for 2.0.16 at this time.
And I would like to only accept bug fixes at this time and take take
features patches once 2.0.16 has been released.

The pre-release can be downloaded from kernel.org:

	https://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.16-rc1.tar.xz
	https://kernel.org/pub/linux/utils/kernel/kexec/

I have also tagged it in git:

	https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git

Thanks to everyone who has contributed to kexec.


For reference the changes since v2.0.15 are:

b047ace53677 kexec-tools 2.0.16-rc1
e08d26b3b7f1 vmcore-dmesg: avoid allocating large memory chunk for log buf
9004e19ca2e7 ARM: read kernel size from zImage
34bf700f981a ARM: cleanup initrd and dtb handing
c06753313db7 kexec-tools: mips: Use proper page_offset for OCTEON CPUs.
77e769bd1d1f kexec-tools: mips: Merge adjacent memory ranges.
508c7d45e270 kexec-tools: mips: Try to include bss in kernel vmcore file.
552bfbfc00ee kexec-tools: mips: Don't set lowmem_limit to 2G for 64-bit systems.
69431282f075 kexec-tools: ppc64: fix leak while checking for coherent device memory
aec4d0f7a250 kexec-tools: ppc64: avoid adding coherent memory regions to crash memory ranges
21eb397a5fc9 kexec-tools: powerpc: fix command line overflow error
47478ea66d43 kexec-tools: ppc64: fix how RMA top is deduced
161dd0f4f8a8 kexec-tools 2.0.15.git


From yang.shunyong at gmail.com  Fri Nov 10 02:22:48 2017
From: yang.shunyong at gmail.com (Yang Shunyong)
Date: Fri, 10 Nov 2017 18:22:48 +0800
Subject: About command line for kdump on ARM64
Message-ID: <CAHnJXBhSY1ms_ts=pXJo+kSjCFUuProJjg5vY8MLM_kDsPY1Jw@mail.gmail.com>

Hi, All,
    I am trying to enable kdump on ARM64, based on 4.14 kernel.  I met
EFI reserved memory(eg. ACPI tables) being released issue, in function
arm64_memblock_init() . It will cause the memory attribute incorrect
and kernel crash in ACPI parsing.
    From the discussions about kdump on ARM64 I searched via Google,
it needs to set some memory configurations, like "mem=". I have set
the "mem=64M", but it still failed.
    Could you please share me some sample command line settings for
kdump ARM64? Or how to set options to avoid  the crash?

following is my command line from "kdump-config show", I have reserved
256M for crash in first kernel "crashkernel=256M at 0x0efe00000",

  /sbin/kexec -p --command-line="BOOT_IMAGE=/vmlinuz-4.14.0-rc2-hxtysy
root=/dev/mapper/ubuntu--vg-root ro rqpoll mem=256M nr_cpus=1 nousb
systemd.unit=kdump-tools.service ns_log_on=on"
--initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz

Thanks


From bhupesh.linux at gmail.com  Fri Nov 10 03:25:03 2017
From: bhupesh.linux at gmail.com (Bhupesh SHARMA)
Date: Fri, 10 Nov 2017 16:55:03 +0530
Subject: About command line for kdump on ARM64
In-Reply-To: <CAHnJXBhSY1ms_ts=pXJo+kSjCFUuProJjg5vY8MLM_kDsPY1Jw@mail.gmail.com>
References: <CAHnJXBhSY1ms_ts=pXJo+kSjCFUuProJjg5vY8MLM_kDsPY1Jw@mail.gmail.com>
Message-ID: <CAFTCetSMsD7ykTeKFiZV8ZiA8Kr3aBRyh16=XKZcLAY4_n6Fqw@mail.gmail.com>

Hello Yang Shunyong,

On Fri, Nov 10, 2017 at 3:52 PM, Yang Shunyong <yang.shunyong at gmail.com> wrote:
> Hi, All,
>     I am trying to enable kdump on ARM64, based on 4.14 kernel.  I met
> EFI reserved memory(eg. ACPI tables) being released issue, in function
> arm64_memblock_init() . It will cause the memory attribute incorrect
> and kernel crash in ACPI parsing.
>     From the discussions about kdump on ARM64 I searched via Google,
> it needs to set some memory configurations, like "mem=". I have set
> the "mem=64M", but it still failed.
>     Could you please share me some sample command line settings for
> kdump ARM64? Or how to set options to avoid  the crash?
>
> following is my command line from "kdump-config show", I have reserved
> 256M for crash in first kernel "crashkernel=256M at 0x0efe00000",
>
>   /sbin/kexec -p --command-line="BOOT_IMAGE=/vmlinuz-4.14.0-rc2-hxtysy
> root=/dev/mapper/ubuntu--vg-root ro rqpoll mem=256M nr_cpus=1 nousb
> systemd.unit=kdump-tools.service ns_log_on=on"
> --initrd=/var/lib/kdump/initrd.img /var/lib/kdump/vmlinuz
>

Yes, I am aware of this issue and debugging the same (see
https://bugzilla.redhat.com/show_bug.cgi?id=1505314 for details).

I plan to post a patch fixing this issue early next week.
I will keep you posted and also share an early version of the patch
with you so that you can check if the same works for you.

Regards,
Bhupesh


From hbathini at linux.vnet.ibm.com  Fri Nov 10 09:13:41 2017
From: hbathini at linux.vnet.ibm.com (Hari Bathini)
Date: Fri, 10 Nov 2017 22:43:41 +0530
Subject: [makedumpfile PATCH] ppc64: update hash page table geometry
Message-ID: <151033402186.13486.3228487082738293986.stgit@hbathini.in.ibm.com>

Starting with kernel 4.12, BOOK3S hash page table geometry is updated
to accommodate larger virtual address range. Update here accordingly.

Signed-off-by: Hari Bathini <hbathini at linux.vnet.ibm.com>
---
 arch/ppc64.c   |   12 +++++++++---
 makedumpfile.h |    3 +++
 2 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/ppc64.c b/arch/ppc64.c
index 2f5a0da..8bdbcc5 100644
--- a/arch/ppc64.c
+++ b/arch/ppc64.c
@@ -245,10 +245,16 @@ ppc64_vmalloc_init(void)
 
 		} else if (info->kernel_version >= KERNEL_VERSION(4, 6, 0)) {
 			info->l1_index_size = PTE_INDEX_SIZE_L4_64K_3_10;
-			info->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_6;
-			info->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_6;
-			info->l4_index_size = PGD_INDEX_SIZE_L4_64K_3_10;
 
+			if (info->kernel_version >= KERNEL_VERSION(4, 12, 0)) {
+				info->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_12;
+				info->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_12;
+				info->l4_index_size = PGD_INDEX_SIZE_L4_64K_4_12;
+			} else {
+				info->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_6;
+				info->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_6;
+				info->l4_index_size = PGD_INDEX_SIZE_L4_64K_3_10;
+			}
 		} else if (info->kernel_version >= KERNEL_VERSION(3, 10, 0)) {
 			info->l1_index_size = PTE_INDEX_SIZE_L4_64K_3_10;
 			info->l2_index_size = PMD_INDEX_SIZE_L4_64K_3_10;
diff --git a/makedumpfile.h b/makedumpfile.h
index db75379..b983aaf 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -670,6 +670,9 @@ unsigned long get_kvbase_arm64(void);
 #define PGD_INDEX_SIZE_L4_64K_3_10  12
 #define PMD_INDEX_SIZE_L4_64K_4_6  5
 #define PUD_INDEX_SIZE_L4_64K_4_6  5
+#define PMD_INDEX_SIZE_L4_64K_4_12 10
+#define PUD_INDEX_SIZE_L4_64K_4_12 7
+#define PGD_INDEX_SIZE_L4_64K_4_12 8
 #define PTE_INDEX_SIZE_RADIX_64K  5
 #define PMD_INDEX_SIZE_RADIX_64K  9
 #define PUD_INDEX_SIZE_RADIX_64K  9



From bhe at redhat.com  Sun Nov 12 00:04:26 2017
From: bhe at redhat.com (Baoquan He)
Date: Sun, 12 Nov 2017 16:04:26 +0800
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171107153428.ex27nwkvelhm2nm7@dwarf.suse.cz>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
 <20171106024143.GA3669@x1>
 <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
 <20171106092729.GB3669@x1>
 <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz>
 <20171107113956.GC3669@x1>
 <20171107134212.tmjdt7rdailtbosa@dwarf.suse.cz>
 <20171107153428.ex27nwkvelhm2nm7@dwarf.suse.cz>
Message-ID: <20171112080426.GB6429@x1>

On 11/07/17 at 04:34pm, Jiri Bohac wrote:
> On Tue, Nov 07, 2017 at 02:42:12PM +0100, Jiri Bohac wrote:
> > On Tue, Nov 07, 2017 at 07:39:56PM +0800, Baoquan He wrote:
> > > don't worry about the user space kexec utility either. 
> > 
> > What's the problem with the userspace kexec? The bug is in
> > reading /proc/vmcore by makedumpfile. kexec would only operate
> > within the preallocated crashkernel area, right?
> 
> right, I see it (without -s the kexec userspace creates the ELF header
> later used the second kernel for /proc/vmcore).

Yes, I meant this. In kernel, you can define global variable to store
the starting address and end of GART aperture. While, in user space
there's no way to know that. Now the non '-s' kexec are still being used
by most of people.

I roughly went through agp3.0 doc and GART code, the root cause for this
issue should be:

AMD system with GART need be enabled in BIOS in principle. Then firmware
will arrange a hole in system address space, defaultly it's 64MB for GART
aperture mapping, below and close to 4G usually. GART stands for Graphic
Address Remap Table, each of its entry can be used to refer to a address
region in the 64M of aperture for iommu usage.

However, in your testing AMD system, you don't enable GART IOMMU support
in BIOS setting. So the current implementation in kernel is to find a
region which is occupied by system RAM and configre the starting addr
and size into GART cofig registers' AMD64_GARTAPERTURECTL and
AMD64_GARTAPERTUREBASE. And this happens in the first kernel. I believe
in kdump kernel, since only resereved crashkernel region is taken as
available system RAM, the rest of original RAM space is seen as hole.
So kdump kernel will still use the 1st kernel's aperture region for GART,
and it also has been set in GART register, kdump kernel think it as BIOS
has reserved hole for GART aperture.

Now the problem is that those pages reserved for GART aperture have been
added into mm subsystem. GART is located on North Bridge. But when CPU
try to access these them, will check North Bridge chip firstly, then
hardware error occured that region has been set in GART registers which
locates in NB.

Solution:
1) Remove the code which support GART IOMMU when it's not enabled in
BIOS. This has been done in the new generation of hardware IOMMU like
intel vt-d IOMMU and amd-Vi IOMMU. We should not make GART IOMMU be
exceptional.

2) Remove those pages from mm subsystem since they are not seen any more
though they have been added into mm subsystem, because CPU can't see
them.

3) Remove the apreture region from /proc/iomem so that pages in that
region can't be seen by kdump kernel. This is easier, but just a work
around.

Hi Yinghai, Joerg, and Bjorn

Found patches you contributed to GART IOMMU, do you have any suggestion
about this issue? Or any comment about these 3 options? 

I personally prefer the 1st one.

Thanks
Baoquan

> 
> No idea how to fix that nicely...
> 
> -- 
> Jiri Bohac <jbohac at suse.cz>
> SUSE Labs, Prague, Czechia
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


From bhe at redhat.com  Sun Nov 12 02:23:57 2017
From: bhe at redhat.com (Baoquan He)
Date: Sun, 12 Nov 2017 18:23:57 +0800
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171112080426.GB6429@x1>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
 <20171106024143.GA3669@x1>
 <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
 <20171106092729.GB3669@x1>
 <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz>
 <20171107113956.GC3669@x1>
 <20171107134212.tmjdt7rdailtbosa@dwarf.suse.cz>
 <20171107153428.ex27nwkvelhm2nm7@dwarf.suse.cz>
 <20171112080426.GB6429@x1>
Message-ID: <20171112102357.GA10474@x1>

On 11/12/17 at 04:04pm, Baoquan He wrote:
> On 11/07/17 at 04:34pm, Jiri Bohac wrote:
> > On Tue, Nov 07, 2017 at 02:42:12PM +0100, Jiri Bohac wrote:
> > > On Tue, Nov 07, 2017 at 07:39:56PM +0800, Baoquan He wrote:
> > > > don't worry about the user space kexec utility either. 
> > > 
> > > What's the problem with the userspace kexec? The bug is in
> > > reading /proc/vmcore by makedumpfile. kexec would only operate
> > > within the preallocated crashkernel area, right?
> > 
> > right, I see it (without -s the kexec userspace creates the ELF header
> > later used the second kernel for /proc/vmcore).
> 
> Yes, I meant this. In kernel, you can define global variable to store
> the starting address and end of GART aperture. While, in user space
> there's no way to know that. Now the non '-s' kexec are still being used
> by most of people.
> 
> I roughly went through agp3.0 doc and GART code, the root cause for this
> issue should be:
> 
> AMD system with GART need be enabled in BIOS in principle. Then firmware
> will arrange a hole in system address space, defaultly it's 64MB for GART
> aperture mapping, below and close to 4G usually. GART stands for Graphic
> Address Remap Table, each of its entry can be used to refer to a address
> region in the 64M of aperture for iommu usage.
> 
> However, in your testing AMD system, you don't enable GART IOMMU support
> in BIOS setting. So the current implementation in kernel is to find a
> region which is occupied by system RAM and configre the starting addr
> and size into GART cofig registers' AMD64_GARTAPERTURECTL and
> AMD64_GARTAPERTUREBASE. And this happens in the first kernel. I believe
> in kdump kernel, since only resereved crashkernel region is taken as
> available system RAM, the rest of original RAM space is seen as hole.
> So kdump kernel will still use the 1st kernel's aperture region for GART,
> and it also has been set in GART register, kdump kernel think it as BIOS
> has reserved hole for GART aperture.
> 
> Now the problem is that those pages reserved for GART aperture have been
> added into mm subsystem. GART is located on North Bridge. But when CPU
> try to access these them, will check North Bridge chip firstly, then
> hardware error occured that region has been set in GART registers which
                        ^since (missed)
> locates in NB.
> 
> Solution:
> 1) Remove the code which support GART IOMMU when it's not enabled in
> BIOS. This has been done in the new generation of hardware IOMMU like
> intel vt-d IOMMU and amd-Vi IOMMU. We should not make GART IOMMU be
> exceptional.
> 
> 2) Remove those pages from mm subsystem since they are not seen any more
> though they have been added into mm subsystem, because CPU can't see
> them.
> 
> 3) Remove the apreture region from /proc/iomem so that pages in that
> region can't be seen by kdump kernel. This is easier, but just a work
> around.
> 
> Hi Yinghai, Joerg, and Bjorn
> 
> Found patches you contributed to GART IOMMU, do you have any suggestion
> about this issue? Or any comment about these 3 options? 
> 
> I personally prefer the 1st one.
> 
> Thanks
> Baoquan
> 
> > 
> > No idea how to fix that nicely...
> > 
> > -- 
> > Jiri Bohac <jbohac at suse.cz>
> > SUSE Labs, Prague, Czechia
> > 
> > 
> > _______________________________________________
> > kexec mailing list
> > kexec at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/kexec
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


From dyoung at redhat.com  Sun Nov 12 21:27:12 2017
From: dyoung at redhat.com (Dave Young)
Date: Mon, 13 Nov 2017 13:27:12 +0800
Subject: [PATCH 2/3] X86/kdump: crashkernel=X try to reserve below 896M
 first then below 4G and MAXMEM
In-Reply-To: <20171024053901.757504190@redhat.com>
References: <20171024053901.757504190@redhat.com>
Message-ID: <20171113052712.GA4894@dhcp-128-65.nay.redhat.com>

On 10/24/17 at 01:31pm, Dave Young wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size.  One can use
> crashkernel=xM,high to reserve it at high region (>4G) but it is more
> convinient to improve crashkernel=X to: 
> 
>  - First try to reserve X below 896M (for being compatible with old
>    kexec-tools).
>  - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
>  - If fails, try to reserve X from MAXMEM top down.
> 
> It's more transparent and user-friendly.
> 
> If crashkernel is large and the reserved is beyond 896M, old kexec-tools
> is not compatible with new kernel because old kexec-tools can not load
> kernel at high memory region, there was an old discussion below:
> https://lkml.org/lkml/2013/10/15/601
> 
> But actually the behavior is consistent during my test. Suppose
> old kernel fail to reserve memory at low areas, kdump does not
> work because no meory reserved. With this patch, suppose new kernel
> successfully reserved memory at high areas, old kexec-tools still fail
> to load kdump kernel (tested 2.0.2), so it is acceptable, no need to
> worry about the compatibility.
> 
> Here is the test result (kexec-tools 2.0.2, no high memory load
> support):
> Crashkernel over 4G:
> # cat /proc/iomem|grep Crash
>   be000000-cdffffff : Crash kernel
>   213000000-21effffff : Crash kernel
> # ./kexec  -p /boot/vmlinuz-`uname -r`
> Memory for crashkernel is not reserved
> Please reserve memory by passing "crashkernel=X at Y" parameter to the kernel
> Then try loading kdump kernel
> 
> crashkernel: 896M-4G:
> # cat /proc/iomem|grep Crash
>   96000000-cdefffff : Crash kernel
> # ./kexec -p /boot/vmlinuz-4.14.0-rc4+
> ELF core (kcore) parse failed
> Cannot load /boot/vmlinuz-4.14.0-rc4+
> 
> Signed-off-by: Dave Young <dyoung at redhat.com>
> ---
>  arch/x86/kernel/setup.c |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> --- linux-x86.orig/arch/x86/kernel/setup.c
> +++ linux-x86/arch/x86/kernel/setup.c
> @@ -568,6 +568,22 @@ static void __init reserve_crashkernel(v
>  						    high ? CRASH_ADDR_HIGH_MAX
>  							 : CRASH_ADDR_LOW_MAX,
>  						    crash_size, CRASH_ALIGN);
> +#ifdef CONFIG_X86_64
> +		/*
> +		 * crashkernel=X reserve below 896M fails? Try below 4G
> +		 */
> +		if (!high && !crash_base)
> +			crash_base = memblock_find_in_range(CRASH_ALIGN,
> +						(1ULL << 32),
> +						crash_size, CRASH_ALIGN);
> +		/*
> +		 * crashkernel=X reserve below 4G fails? Try MAXMEM
> +		 */
> +		if (!high && !crash_base)
> +			crash_base = memblock_find_in_range(CRASH_ALIGN,
> +						CRASH_ADDR_HIGH_MAX,
> +						crash_size, CRASH_ALIGN);
> +#endif
>  		if (!crash_base) {
>  			pr_info("crashkernel reservation failed - No suitable area found.\n");
>  			return;
> 
> 

Andrew, this patch is good to have, could you take this in your tree?
The other two patches may need more discussion I will drop them for now.

Thanks
Dave


From dyoung at redhat.com  Sun Nov 12 21:43:11 2017
From: dyoung at redhat.com (Dave Young)
Date: Mon, 13 Nov 2017 13:43:11 +0800
Subject: [PATCH] kdump: print a message in case crashkernel size parsing
 resulted in zero bytes
Message-ID: <20171113054311.GA4971@dhcp-128-65.nay.redhat.com>

In parse_crashkernel_mem, it silently return in case we get zero
bytes in the parsing function.  It is useful for debugging for
adding a warning message especially sometimes kernel can not boot
up correctly.

Signed-off-by: Dave Young <dyoung at redhat.com>
---
 kernel/crash_core.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-x86.orig/kernel/crash_core.c
+++ linux-x86/kernel/crash_core.c
@@ -108,7 +108,8 @@ static int __init parse_crashkernel_mem(
 				return -EINVAL;
 			}
 		}
-	}
+	} else
+		pr_warn("crashkernel size resulted in zero bytes\n");
 
 	return 0;
 }


From jbohac at suse.cz  Mon Nov  6 01:01:55 2017
From: jbohac at suse.cz (Jiri Bohac)
Date: Mon, 6 Nov 2017 10:01:55 +0100
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171106024143.GA3669@x1>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
 <20171106024143.GA3669@x1>
Message-ID: <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>

Hi Baoquan,

On Mon, Nov 06, 2017 at 10:41:43AM +0800, Baoquan He wrote:
> Is this reproduced on a machine with GART existing and passing test with
> this patch applied? Do you have a /proc/iomem printing about the machine
> you are testing on?

I've seen this on at least three different machines. Two of them,
I am able to test things on. The one I've been using to test the
patch is not a production system, but that should not play any role here:


excerpts of /proc/cpuinfo (first CPU only):
	processor	: 0
	vendor_id	: AuthenticAMD
	cpu family	: 16
	model		: 9
	model name	: AMD Engineering Sample
	stepping	: 1
	microcode	: 0x10000c4
	cpu MHz		: 1695.829
	cache size	: 512 KB
	physical id	: 0
	siblings	: 12
	core id		: 0
	cpu cores	: 12
	flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt nodeid_msr hw_pstate vmmcall npt lbrv svm_lock nrip_save pausefilter
	bugs		: tlb_mmatch fxsave_leak sysret_ss_attrs null_seg
	address sizes	: 48 bits physical, 48 bits virtual
	power management: ts ttp tm stc 100mhzsteps hwpstate


excerpts of dmesg:
	[    0.000000] Linux version 4.14.0-rc7-test-default (geeko at buildhost) (gcc version 4.8.5 (SUSE Linux)) #1 SMP PREEMPT Tue Oct 31 14:21:34 UTC 2017 (e7b14aa)
	[    0.000000] Command line: root=/dev/sda2 console=tty0 console=ttyS0,115200 audit=0 vga=6 showopts crashkernel=101M,high crashkernel=72M,low memblock=debug
	[    0.000000] x86/fpu: x87 FPU will use FXSAVE
	[    0.000000] e820: BIOS-provided physical RAM map:
	[    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable
	[    0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved
	[    0.000000] BIOS-e820: [mem 0x00000000000ce000-0x00000000000fffff] reserved
	[    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000c7e7ffff] usable
	[    0.000000] BIOS-e820: [mem 0x00000000c7e80000-0x00000000c7e8afff] ACPI data
	[    0.000000] BIOS-e820: [mem 0x00000000c7e8b000-0x00000000c7e8cfff] ACPI NVS
	[    0.000000] BIOS-e820: [mem 0x00000000c7e8d000-0x00000000c7ffffff] reserved
	[    0.000000] BIOS-e820: [mem 0x00000000e0000000-0x00000000efffffff] reserved
	[    0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved
	[    0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
	[    0.000000] BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
	[    0.000000] BIOS-e820: [mem 0x0000000100000000-0x0000000837ffffff] usable
	[    0.000000] NX (Execute Disable) protection: active
	[    0.000000] random: fast init done
	[    0.000000] SMBIOS 2.5 present.
	[    0.000000] DMI: AMD Dinar/Dinar, BIOS PDNAX2-0 07/12/2010
	[    0.000000] tsc: Fast TSC calibration using PIT
	[    0.000000] e820: update [mem 0x00000000-0x00000fff] usable ==> reserved
	[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
	[    0.000000] AGP: No AGP bridge found
	[    0.000000] e820: last_pfn = 0x838000 max_arch_pfn = 0x400000000
	[    0.000000] MTRR default type: uncachable
	[    0.000000] MTRR fixed ranges enabled:
	[    0.000000]   00000-9FFFF write-back
	[    0.000000]   A0000-BFFFF uncachable
	[    0.000000]   C0000-CFFFF write-protect
	[    0.000000]   D0000-DFFFF uncachable
	[    0.000000]   E0000-FFFFF write-protect
	[    0.000000] MTRR variable ranges enabled:
	[    0.000000]   0 base 000000000000 mask FFFF80000000 write-back
	[    0.000000]   1 base 000080000000 mask FFFFC0000000 write-back
	[    0.000000]   2 base 0000C0000000 mask FFFFF8000000 write-back
	[    0.000000]   3 disabled
	[    0.000000]   4 disabled
	[    0.000000]   5 disabled
	[    0.000000]   6 disabled
	[    0.000000]   7 disabled
	[    0.000000] TOM2: 0000000838000000 aka 33664M
	[    0.000000] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
	[    0.000000] e820: update [mem 0xc8000000-0xffffffff] usable ==> reserved
	[    0.000000] e820: last_pfn = 0xc7e80 max_arch_pfn = 0x400000000
	[    0.000000] found SMP MP-table at [mem 0x000f7980-0x000f798f] mapped at [ffffffffff000980]
	[    0.000000] memblock_reserve: [0x00000000000f7980-0x00000000000f798f] smp_scan_config+0xd0/0x102
	[    0.000000] memblock_reserve: [0x000000000009ddb1-0x000000000009e0b4] smp_scan_config+0xed/0x102
	[    0.000000] memblock_reserve: [0x00000004e03c9000-0x00000004e03d5fff] setup_arch+0x5dc/0xcba
	[    0.000000] memblock_add: [0x0000000000001000-0x000000000009d7ff] e820__memblock_setup+0x42/0x61
	[    0.000000] memblock_add: [0x0000000000100000-0x00000000c7e7ffff] e820__memblock_setup+0x42/0x61
	[    0.000000] memblock_add: [0x0000000100000000-0x0000000837ffffff] e820__memblock_setup+0x42/0x61
	[    0.000000] MEMBLOCK configuration:
	[    0.000000]  memory size = 0x00000007ffe1c800 reserved size = 0x00000000029b0314
	[    0.000000]  memory.cnt  = 0x3
	[    0.000000]  memory[0x0]	[0x0000000000001000-0x000000000009cfff], 0x000000000009c000 bytes flags: 0x0
	[    0.000000]  memory[0x1]	[0x0000000000100000-0x00000000c7e7ffff], 0x00000000c7d80000 bytes flags: 0x0
	[    0.000000]  memory[0x2]	[0x0000000100000000-0x0000000837ffffff], 0x0000000738000000 bytes flags: 0x0
	[    0.000000]  reserved.cnt  = 0x4
	[    0.000000]  reserved[0x0]	[0x000000000009ddb1-0x000000000009e0b4], 0x0000000000000304 bytes flags: 0x0
	[    0.000000]  reserved[0x1]	[0x00000000000f7980-0x00000000000f798f], 0x0000000000000010 bytes flags: 0x0
	[    0.000000]  reserved[0x2]	[0x0000000036a16000-0x0000000037feffff], 0x00000000015da000 bytes flags: 0x0
	[    0.000000]  reserved[0x3]	[0x00000004df000000-0x00000004e03d5fff], 0x00000000013d6000 bytes flags: 0x0
	[    0.000000] memblock_reserve: [0x000000000009d800-0x00000000000fffff] setup_arch+0x60e/0xcba
	[    0.000000] memblock_reserve: [0x0000000000001000-0x000000000000ffff] setup_bios_corruption_check+0xfa/0x195
	[    0.000000] Scanning 1 areas for low memory corruption
	[    0.000000] memblock_reserve: [0x0000000000097000-0x000000000009cfff] reserve_real_mode+0x6a/0x7a
	[    0.000000] Base memory trampoline at [ffff9154c0097000] 97000 size 24576
	[    0.000000] memblock_reserve: [0x0000000000000000-0x000000000000ffff] setup_arch+0x6f7/0xcba
	[    0.000000] Using GB pages for direct mapping
	[    0.000000] BRK [0x4e03ca000, 0x4e03cafff] PGTABLE
	[    0.000000] BRK [0x4e03cb000, 0x4e03cbfff] PGTABLE
	[    0.000000] BRK [0x4e03cc000, 0x4e03ccfff] PGTABLE
	[    0.000000] BRK [0x4e03cd000, 0x4e03cdfff] PGTABLE
	[    0.000000] BRK [0x4e03ce000, 0x4e03cefff] PGTABLE
	[    0.000000] BRK [0x4e03cf000, 0x4e03cffff] PGTABLE
	[    0.000000] BRK [0x4e03d0000, 0x4e03d0fff] PGTABLE
	[    0.000000] RAMDISK: [mem 0x36a16000-0x37feffff]
	[    0.000000] ACPI: Early table checksum verification disabled
	[    0.000000] ACPI: RSDP 0x00000000000F7900 000024 (v02 PTLTD )
	[    0.000000] ACPI: XSDT 0x00000000C7E8081A 00006C (v01 PTLTD  ? XSDT   06040000  LTP 00000000)
	[    0.000000] ACPI: FACP 0x00000000C7E86C3F 0000F4 (v03 AMD    Dinar    06040000 AMD  000F4240)
	[    0.000000] ACPI: DSDT 0x00000000C7E80886 0063B9 (v02 AMD    SB700    06040000 MSFT 03000000)
	[    0.000000] ACPI: FACS 0x00000000C7E8CFC0 000040
	[    0.000000] ACPI: FACS 0x00000000C7E8CFC0 000040
	[    0.000000] ACPI: TCPA 0x00000000C7E86DA7 000032 (v02 AMD             06040000 PTEC 00000000)
	[    0.000000] ACPI: SLIT 0x00000000C7E86DD9 00003C (v01 AMD    F10      06040000 AMD  00000001)
	[    0.000000] ACPI: SRAT 0x00000000C7E86E15 000278 (v02 AMD    F10      06040000 AMD  00000001)
	[    0.000000] ACPI: SSDT 0x00000000C7E8708D 003C6C (v01 AMD    POWERNOW 06040000 AMD  00000001)
	[    0.000000] ACPI: SSDT 0x00000000C7E8ACF9 0000F5 (v01 AMD-K8 AMD-ACPI 06040000  AMD 00000001)
	[    0.000000] ACPI: APIC 0x00000000C7E8ADEE 00019E (v01 PTLTD  ? APIC   06040000  LTP 00000000)
	[    0.000000] ACPI: MCFG 0x00000000C7E8AF8C 00003C (v01 PTLTD    MCFG   06040000  LTP 00000000)
	[    0.000000] ACPI: HPET 0x00000000C7E8AFC8 000038 (v01 PTLTD  HPETTBL  06040000  LTP 00000001)
	[    0.000000] ACPI: Local APIC address 0xfee00000
...
	[    0.000000] memblock_reserve: [0x0000000837fff000-0x0000000837fff00f] numa_set_distance+0x102/0x1f6
	[    0.000000] NUMA: Initialized distance table, cnt=4
	[    0.000000] NUMA: Node 0 [mem 0x00000000-0x0009ffff] + [mem 0x00100000-0xc7ffffff] -> [mem 0x00000000-0xc7ffffff]
	[    0.000000] NUMA: Node 0 [mem 0x00000000-0xc7ffffff] + [mem 0x100000000-0x2b7ffffff] -> [mem 0x00000000-0x2b7ffffff]
	[    0.000000] memblock_reserve: [0x00000002b7fea000-0x00000002b7ffffff] memblock_alloc_range_nid+0x32/0x3c
	[    0.000000] NODE_DATA(0) allocated [mem 0x2b7fea000-0x2b7ffffff]
	[    0.000000] memblock_reserve: [0x00000003b7fea000-0x00000003b7ffffff] memblock_alloc_range_nid+0x32/0x3c
	[    0.000000] NODE_DATA(1) allocated [mem 0x3b7fea000-0x3b7ffffff]
	[    0.000000] memblock_reserve: [0x0000000837fe9000-0x0000000837ffefff] memblock_alloc_range_nid+0x32/0x3c
	[    0.000000] NODE_DATA(2) allocated [mem 0x837fe9000-0x837ffefff]
	[    0.000000] MEMBLOCK configuration:
	[    0.000000]  memory size = 0x00000007ffe1c800 reserved size = 0x0000000002a6a810
	[    0.000000]  memory.cnt  = 0x5
	[    0.000000]  memory[0x0]	[0x0000000000001000-0x000000000009cfff], 0x000000000009c000 bytes on node 0 flags: 0x0
	[    0.000000]  memory[0x1]	[0x0000000000100000-0x00000000c7e7ffff], 0x00000000c7d80000 bytes on node 0 flags: 0x0
	[    0.000000]  memory[0x2]	[0x0000000100000000-0x00000002b7ffffff], 0x00000001b8000000 bytes on node 0 flags: 0x0
	[    0.000000]  memory[0x3]	[0x00000002b8000000-0x00000003b7ffffff], 0x0000000100000000 bytes on node 1 flags: 0x0
	[    0.000000]  memory[0x4]	[0x00000003b8000000-0x0000000837ffffff], 0x0000000480000000 bytes on node 2 flags: 0x0
	[    0.000000]  reserved.cnt  = 0x9
	[    0.000000]  reserved[0x0]	[0x0000000000000000-0x000000000000ffff], 0x0000000000010000 bytes on node 0 flags: 0x0
	[    0.000000]  reserved[0x1]	[0x0000000000097000-0x000000000009cfff], 0x0000000000006000 bytes on node 0 flags: 0x0
	[    0.000000]  reserved[0x2]	[0x000000000009d800-0x00000000000fffff], 0x0000000000062800 bytes on node 0 flags: 0x0
	[    0.000000]  reserved[0x3]	[0x0000000036a16000-0x0000000037feffff], 0x00000000015da000 bytes on node 0 flags: 0x0
	[    0.000000]  reserved[0x4]	[0x00000002b7fea000-0x00000002b7ffffff], 0x0000000000016000 bytes flags: 0x0
	[    0.000000]  reserved[0x5]	[0x00000003b7fea000-0x00000003b7ffffff], 0x0000000000016000 bytes flags: 0x0
	[    0.000000]  reserved[0x6]	[0x00000004df000000-0x00000004e03d5fff], 0x00000000013d6000 bytes on node 2 flags: 0x0
	[    0.000000]  reserved[0x7]	[0x0000000837fe9000-0x0000000837ffefff], 0x0000000000016000 bytes flags: 0x0
	[    0.000000]  reserved[0x8]	[0x0000000837fff000-0x0000000837fff00f], 0x0000000000000010 bytes on node 2 flags: 0x0
	[    0.000000] memblock_reserve: [0x0000000831000000-0x00000008374fffff] setup_arch+0xa4a/0xcba
	[    0.000000] memblock_reserve: [0x00000000c3000000-0x00000000c77fffff] setup_arch+0xb1e/0xcba
	[    0.000000] Reserving 72MB of low memory at 3120MB for crashkernel (System low RAM: 3198MB)
	[    0.000000] Reserving 101MB of memory at 33552MB for crashkernel (System RAM: 32766MB)
	[    0.000000] memblock_virt_alloc_try_nid: 4096 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 memory_present+0x67/0xb0
	[    0.000000] memblock_reserve: [0x00000002b7fe9000-0x00000002b7fe9fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 4096 bytes align=0x0 nid=2 from=0x0 max_addr=0x0 memory_present+0x67/0xb0
	[    0.000000] memblock_reserve: [0x0000000837fe8000-0x0000000837fe8fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 4194304 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 sparse_init+0x22/0x14b
	[    0.000000] memblock_reserve: [0x0000000837be8000-0x0000000837fe7fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid_nopanic: 2560 bytes align=0x40 nid=0 from=0x2b0000000 max_addr=0x2b8000000 sparse_early_usemaps_alloc_node+0x8d/0x202
	[    0.000000] memblock_reserve: [0x00000002b7fe8600-0x00000002b7fe8fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid_nopanic: 1024 bytes align=0x40 nid=1 from=0x3b0000000 max_addr=0x3b8000000 sparse_early_usemaps_alloc_node+0x8d/0x202
	[    0.000000] memblock_reserve: [0x00000003b7fe9c00-0x00000003b7fe9fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid_nopanic: 4608 bytes align=0x40 nid=2 from=0x830000000 max_addr=0x838000000 sparse_early_usemaps_alloc_node+0x8d/0x202
	[    0.000000] memblock_reserve: [0x0000000837be6e00-0x0000000837be7fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 4194304 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 sparse_init+0x5b/0x14b
	[    0.000000] memblock_reserve: [0x00000008377e6e00-0x0000000837be6dff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 167772160 bytes align=0x200000 nid=0 from=0x1000000 max_addr=0x0 sparse_mem_maps_populate_node+0x66/0x168
	[    0.000000] memblock_reserve: [0x00000002ade00000-0x00000002b7dfffff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 4096 bytes align=0x1000 nid=0 from=0x1000000 max_addr=0x0 vmemmap_p4d_populate+0x23/0xaf
	[    0.000000] memblock_reserve: [0x00000002b7fe7000-0x00000002b7fe7fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 4096 bytes align=0x1000 nid=0 from=0x1000000 max_addr=0x0 vmemmap_pud_populate+0x5b/0xe9
	[    0.000000] memblock_reserve: [0x00000002b7fe6000-0x00000002b7fe6fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] __memblock_free_early: [0x000002b7e00000-0x000002b7dfffff] sparse_mem_maps_populate_node+0xf9/0x168
	[    0.000000] memblock_virt_alloc_try_nid: 67108864 bytes align=0x200000 nid=1 from=0x1000000 max_addr=0x0 sparse_mem_maps_populate_node+0x66/0x168
	[    0.000000] memblock_reserve: [0x00000003b3e00000-0x00000003b7dfffff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] __memblock_free_early: [0x000003b7e00000-0x000003b7dfffff] sparse_mem_maps_populate_node+0xf9/0x168
	[    0.000000] memblock_virt_alloc_try_nid: 301989888 bytes align=0x200000 nid=2 from=0x1000000 max_addr=0x0 sparse_mem_maps_populate_node+0x66/0x168
	[    0.000000] memblock_reserve: [0x000000081f000000-0x0000000830ffffff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] __memblock_free_early: [0x00000831000000-0x00000830ffffff] sparse_mem_maps_populate_node+0xf9/0x168
	[    0.000000] __memblock_free_early: [0x000008377e6e00-0x00000837be6dff] sparse_init+0x119/0x14b
	[    0.000000] __memblock_free_early: [0x00000837be8000-0x00000837fe7fff] paging_init+0x14/0x31
	[    0.000000] Zone ranges:
	[    0.000000]   DMA      [mem 0x0000000000001000-0x0000000000ffffff]
	[    0.000000]   DMA32    [mem 0x0000000001000000-0x00000000ffffffff]
	[    0.000000]   Normal   [mem 0x0000000100000000-0x0000000837ffffff]
	[    0.000000]   Device   empty
	[    0.000000] Movable zone start for each node
	[    0.000000] Early memory node ranges
	[    0.000000]   node   0: [mem 0x0000000000001000-0x000000000009cfff]
	[    0.000000]   node   0: [mem 0x0000000000100000-0x00000000c7e7ffff]
	[    0.000000]   node   0: [mem 0x0000000100000000-0x00000002b7ffffff]
	[    0.000000]   node   1: [mem 0x00000002b8000000-0x00000003b7ffffff]
	[    0.000000]   node   2: [mem 0x00000003b8000000-0x0000000837ffffff]
	[    0.000000] Initmem setup node 0 [mem 0x0000000000001000-0x00000002b7ffffff]
	[    0.000000] On node 0 totalpages: 2620956
	[    0.000000]   DMA zone: 64 pages used for memmap
	[    0.000000]   DMA zone: 21 pages reserved
	[    0.000000]   DMA zone: 3996 pages, LIFO batch:0
	[    0.000000]   DMA32 zone: 12730 pages used for memmap
	[    0.000000]   DMA32 zone: 814720 pages, LIFO batch:31
	[    0.000000]   Normal zone: 28160 pages used for memmap
	[    0.000000]   Normal zone: 1802240 pages, LIFO batch:31
	[    0.000000] Initmem setup node 1 [mem 0x00000002b8000000-0x00000003b7ffffff]
	[    0.000000] On node 1 totalpages: 1048576
	[    0.000000]   Normal zone: 16384 pages used for memmap
	[    0.000000]   Normal zone: 1048576 pages, LIFO batch:31
	[    0.000000] Initmem setup node 2 [mem 0x00000003b8000000-0x0000000837ffffff]
	[    0.000000] On node 2 totalpages: 4718592
	[    0.000000]   Normal zone: 73728 pages used for memmap
	[    0.000000]   Normal zone: 4718592 pages, LIFO batch:31
	[    0.000000] memblock_reserve: [0x0000000837fe7000-0x0000000837fe7fff] __alloc_memory_core_early+0x84/0xac
...
	[    0.000000] IOAPIC[0]: apic_id 0, version 33, address 0xfec00000, GSI 0-23
	[    0.000000] IOAPIC[1]: apic_id 1, version 33, address 0xc8000000, GSI 24-55
	[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 low level)
	[    0.000000] ACPI: IRQ0 used by override.
	[    0.000000] ACPI: IRQ9 used by override.
	[    0.000000] Using ACPI (MADT) for SMP configuration information
	[    0.000000] ACPI: HPET id: 0x43538301 base: 0xfed00000
	[    0.000000] memblock_reserve: [0x0000000837ffff80-0x0000000837ffffc8] __alloc_memory_core_early+0x84/0xac
	[    0.000000] smpboot: Allowing 24 CPUs, 0 hotplug CPUs
	[    0.000000] memblock_reserve: [0x0000000837fd1000-0x0000000837fe6fff] memblock_alloc_range_nid+0x32/0x3c
	[    0.000000] NODE_DATA(3) allocated [mem 0x837fd1000-0x837fe6fff]
	[    0.000000]     NODE_DATA(3) on node 2
	[    0.000000] Initmem setup node 3 [mem 0x0000000000000000-0x0000000000000000]
	[    0.000000] On node 3 totalpages: 0
	[    0.000000] memblock_reserve: [0x0000000837fffec0-0x0000000837ffff55] __alloc_memory_core_early+0x84/0xac
	[    0.000000] memblock_reserve: [0x0000000837fffb80-0x0000000837fffebf] __alloc_memory_core_early+0x84/0xac
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fffb00-0x0000000837fffb67] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fffa80-0x0000000837fffae7] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fffa00-0x0000000837fffa67] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fff980-0x0000000837fff9e7] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fff900-0x0000000837fff967] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fff880-0x0000000837fff8e7] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fff800-0x0000000837fff867] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fff780-0x0000000837fff7e7] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fff700-0x0000000837fff767] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fff680-0x0000000837fff6e7] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fff600-0x0000000837fff667] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 104 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 firmware_map_add_early+0x26/0x4c
	[    0.000000] memblock_reserve: [0x0000000837fff580-0x0000000837fff5e7] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 32 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 __register_nosave_region+0x74/0xdd
	[    0.000000] memblock_reserve: [0x0000000837fff540-0x0000000837fff55f] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] PM: Registered nosave memory: [mem 0x00000000-0x00000fff]
	[    0.000000] memblock_virt_alloc_try_nid: 32 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 __register_nosave_region+0x74/0xdd
	[    0.000000] memblock_reserve: [0x0000000837fff500-0x0000000837fff51f] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] PM: Registered nosave memory: [mem 0x0009d000-0x0009dfff]
	[    0.000000] PM: Registered nosave memory: [mem 0x0009e000-0x0009ffff]
	[    0.000000] PM: Registered nosave memory: [mem 0x000a0000-0x000cdfff]
	[    0.000000] PM: Registered nosave memory: [mem 0x000ce000-0x000fffff]
	[    0.000000] memblock_virt_alloc_try_nid: 32 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 __register_nosave_region+0x74/0xdd
	[    0.000000] memblock_reserve: [0x0000000837fff4c0-0x0000000837fff4df] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] PM: Registered nosave memory: [mem 0xc7e80000-0xc7e8afff]
	[    0.000000] PM: Registered nosave memory: [mem 0xc7e8b000-0xc7e8cfff]
	[    0.000000] PM: Registered nosave memory: [mem 0xc7e8d000-0xc7ffffff]
	[    0.000000] PM: Registered nosave memory: [mem 0xc8000000-0xdfffffff]
	[    0.000000] PM: Registered nosave memory: [mem 0xe0000000-0xefffffff]
	[    0.000000] PM: Registered nosave memory: [mem 0xf0000000-0xfebfffff]
	[    0.000000] PM: Registered nosave memory: [mem 0xfec00000-0xfec0ffff]
	[    0.000000] PM: Registered nosave memory: [mem 0xfec10000-0xfedfffff]
	[    0.000000] PM: Registered nosave memory: [mem 0xfee00000-0xfee00fff]
	[    0.000000] PM: Registered nosave memory: [mem 0xfee01000-0xffefffff]
	[    0.000000] PM: Registered nosave memory: [mem 0xfff00000-0xffffffff]
	[    0.000000] e820: [mem 0xc8000000-0xdfffffff] available for PCI devices
	[    0.000000] Booting paravirtualized kernel on bare hardware
	[    0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
	[    0.000000] memblock_virt_alloc_try_nid: 129 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 start_kernel+0x107/0x4b0
	[    0.000000] memblock_reserve: [0x0000000837fff400-0x0000000837fff480] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 129 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 start_kernel+0x130/0x4b0
	[    0.000000] memblock_reserve: [0x0000000837fff340-0x0000000837fff3c0] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 129 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 start_kernel+0x159/0x4b0
	[    0.000000] memblock_reserve: [0x0000000837fff280-0x0000000837fff300] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:24 nr_node_ids:4
	[    0.000000] memblock_virt_alloc_try_nid_nopanic: 4096 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_alloc_alloc_info+0x3f/0x74
	[    0.000000] memblock_reserve: [0x0000000837fd0000-0x0000000837fd0fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid_nopanic: 4096 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_embed_first_chunk+0x7d/0x2e5
	[    0.000000] memblock_reserve: [0x0000000837fcf000-0x0000000837fcffff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_reserve: [0x00000002adc00000-0x00000002addfffff] __alloc_memory_core_early+0x84/0xac
	[    0.000000] memblock_reserve: [0x00000003b3c00000-0x00000003b3dfffff] __alloc_memory_core_early+0x84/0xac
	[    0.000000] memblock_reserve: [0x0000000837c00000-0x0000000837dfffff] __alloc_memory_core_early+0x84/0xac
	[    0.000000] memblock_reserve: [0x0000000837800000-0x00000008379fffff] __alloc_memory_core_early+0x84/0xac
	[    0.000000]    memblock_free: [0x00000002adc27000-0x00000002adc3ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000002adc67000-0x00000002adc7ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000002adca7000-0x00000002adcbffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000002adce7000-0x00000002adcfffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000002add27000-0x00000002add3ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000002add67000-0x00000002add7ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000002add80000-0x00000002addbffff] pcpu_embed_first_chunk+0x1a3/0x2e5
	[    0.000000]    memblock_free: [0x00000002addc0000-0x00000002addfffff] pcpu_embed_first_chunk+0x1a3/0x2e5
	[    0.000000]    memblock_free: [0x00000003b3c27000-0x00000003b3c3ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000003b3c67000-0x00000003b3c7ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000003b3ca7000-0x00000003b3cbffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000003b3ce7000-0x00000003b3cfffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000003b3d27000-0x00000003b3d3ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000003b3d67000-0x00000003b3d7ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000003b3d80000-0x00000003b3dbffff] pcpu_embed_first_chunk+0x1a3/0x2e5
	[    0.000000]    memblock_free: [0x00000003b3dc0000-0x00000003b3dfffff] pcpu_embed_first_chunk+0x1a3/0x2e5
	[    0.000000]    memblock_free: [0x0000000837c27000-0x0000000837c3ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x0000000837c67000-0x0000000837c7ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x0000000837ca7000-0x0000000837cbffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x0000000837ce7000-0x0000000837cfffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x0000000837d27000-0x0000000837d3ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x0000000837d67000-0x0000000837d7ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x0000000837d80000-0x0000000837dbffff] pcpu_embed_first_chunk+0x1a3/0x2e5
	[    0.000000]    memblock_free: [0x0000000837dc0000-0x0000000837dfffff] pcpu_embed_first_chunk+0x1a3/0x2e5
	[    0.000000]    memblock_free: [0x0000000837827000-0x000000083783ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x0000000837867000-0x000000083787ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000008378a7000-0x00000008378bffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x00000008378e7000-0x00000008378fffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x0000000837927000-0x000000083793ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x0000000837967000-0x000000083797ffff] pcpu_embed_first_chunk+0x1f7/0x2e5
	[    0.000000]    memblock_free: [0x0000000837980000-0x00000008379bffff] pcpu_embed_first_chunk+0x1a3/0x2e5
	[    0.000000]    memblock_free: [0x00000008379c0000-0x00000008379fffff] pcpu_embed_first_chunk+0x1a3/0x2e5
	[    0.000000] percpu: Embedded 39 pages/cpu @ffff91576dc00000 s121752 r8192 d29800 u262144
	[    0.000000] memblock_virt_alloc_try_nid: 32 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x310/0x6a9
	[    0.000000] memblock_reserve: [0x0000000837fff240-0x0000000837fff25f] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 32 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x320/0x6a9
	[    0.000000] memblock_reserve: [0x0000000837fff200-0x0000000837fff21f] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 96 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x332/0x6a9
	[    0.000000] memblock_reserve: [0x0000000837fff180-0x0000000837fff1df] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 192 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x344/0x6a9
	[    0.000000] memblock_reserve: [0x0000000837fff0c0-0x0000000837fff17f] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] pcpu-alloc: s121752 r8192 d29800 u262144 alloc=1*2097152
	[    0.000000] pcpu-alloc: [0] 00 01 02 03 04 05 -- -- [1] 06 07 08 09 10 11 -- -- 
	[    0.000000] pcpu-alloc: [2] 12 13 14 15 16 17 -- -- [3] 18 19 20 21 22 23 -- -- 
	[    0.000000] memblock_virt_alloc_try_nid: 288 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_setup_first_chunk+0x602/0x6a9
	[    0.000000] memblock_reserve: [0x0000000837fceec0-0x0000000837fcefdf] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 105 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_alloc_first_chunk+0x6a/0x215
	[    0.000000] memblock_reserve: [0x0000000837fff040-0x0000000837fff0a8] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 384 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_alloc_first_chunk+0xa5/0x215
	[    0.000000] memblock_reserve: [0x0000000837fced40-0x0000000837fceebf] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 392 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_alloc_first_chunk+0xc1/0x215
	[    0.000000] memblock_reserve: [0x0000000837fceb80-0x0000000837fced07] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 60 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_alloc_first_chunk+0xd2/0x215
	[    0.000000] memblock_reserve: [0x0000000837fceb40-0x0000000837fceb7b] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 105 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_alloc_first_chunk+0x6a/0x215
	[    0.000000] memblock_reserve: [0x0000000837fceac0-0x0000000837fceb28] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 1024 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_alloc_first_chunk+0xa5/0x215
	[    0.000000] memblock_reserve: [0x0000000837fce6c0-0x0000000837fceabf] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 1032 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_alloc_first_chunk+0xc1/0x215
	[    0.000000] memblock_reserve: [0x0000000837fce280-0x0000000837fce687] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 160 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 pcpu_alloc_first_chunk+0xd2/0x215
	[    0.000000] memblock_reserve: [0x0000000837fce1c0-0x0000000837fce25f] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] __memblock_free_early: [0x00000837fd0000-0x00000837fd0fff] pcpu_embed_first_chunk+0x29c/0x2e5
	[    0.000000] __memblock_free_early: [0x00000837fcf000-0x00000837fcffff] pcpu_embed_first_chunk+0x2d4/0x2e5
	[    0.000000] Built 4 zonelists, mobility grouping on.  Total pages: 8257037
	[    0.000000] Policy zone: Normal
	[    0.000000] Kernel command line: root=/dev/sda2 console=tty0 console=ttyS0,115200 audit=0 vga=6 showopts crashkernel=101M,high crashkernel=72M,low memblock=debug
	[    0.000000] audit: disabled (until reboot)
	[    0.000000] log_buf_len individual max cpu contribution: 32768 bytes
	[    0.000000] log_buf_len total cpu_extra contributions: 753664 bytes
	[    0.000000] log_buf_len min size: 262144 bytes
	[    0.000000] memblock_virt_alloc_try_nid_nopanic: 1048576 bytes align=0x4 nid=-1 from=0x0 max_addr=0x0 setup_log_buf+0xd6/0x1df
	[    0.000000] memblock_reserve: [0x0000000837ece1c0-0x0000000837fce1bf] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] log_buf_len: 1048576 bytes
	[    0.000000] early log buf free: 227236(86%)
	[    0.000000] memblock_virt_alloc_try_nid_nopanic: 32768 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 alloc_large_system_hash+0x15c/0x24b
	[    0.000000] memblock_reserve: [0x0000000837ec61c0-0x0000000837ece1bf] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] PID hash table entries: 4096 (order: 3, 32768 bytes)
	[    0.000000] memblock_virt_alloc_try_nid_nopanic: 67108864 bytes align=0x1000 nid=-1 from=0x0 max_addr=0xffffffff swiotlb_init+0x46/0xa5
	[    0.000000] memblock_reserve: [0x00000000bf000000-0x00000000c2ffffff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid_nopanic: 32768 bytes align=0x1000 nid=-1 from=0x0 max_addr=0xffffffff swiotlb_init_with_tbl+0x60/0x172
	[    0.000000] memblock_reserve: [0x00000000c7e78000-0x00000000c7e7ffff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 131072 bytes align=0x1000 nid=-1 from=0x0 max_addr=0x0 swiotlb_init_with_tbl+0xc4/0x172
	[    0.000000] memblock_reserve: [0x0000000837ea6000-0x0000000837ec5fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] memblock_virt_alloc_try_nid: 262144 bytes align=0x1000 nid=-1 from=0x0 max_addr=0x0 swiotlb_init_with_tbl+0xf3/0x172
	[    0.000000] memblock_reserve: [0x0000000837e66000-0x0000000837ea5fff] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] AGP: Checking aperture...
	[    0.000000] AGP: No AGP bridge found
	[    0.000000] AGP: Node 0: aperture [bus addr 0xac000000-0xadffffff] (32MB)
	[    0.000000] Aperture pointing to e820 RAM. Ignoring.
	[    0.000000] AGP: Your BIOS doesn't leave an aperture memory hole
	[    0.000000] AGP: Please enable the IOMMU option in the BIOS setup
	[    0.000000] AGP: This costs you 64MB of RAM
	[    0.000000] memblock_reserve: [0x00000000b8000000-0x00000000bbffffff] gart_iommu_hole_init+0x396/0x4b6
	[    0.000000] AGP: Mapping aperture over RAM [mem 0xb8000000-0xbbffffff] (65536KB)
^^^^^
	[    0.000000] memblock_virt_alloc_try_nid: 32 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 __register_nosave_region+0x74/0xdd
	[    0.000000] memblock_reserve: [0x0000000837fd0fc0-0x0000000837fd0fdf] memblock_virt_alloc_internal+0xc4/0x14f
	[    0.000000] PM: Registered nosave memory: [mem 0xb8000000-0xbbffffff]
	[    0.000000] Memory: 9601172K/33552496K available (7755K kernel code, 1397K rwdata, 3352K rodata, 1924K init, 1364K bss, 880900K reserved, 0K cma-reserved)
...
	[    3.072003] bus: [bus 00-bf] on node 0 link 3
	[    3.072005] bus: 00 [io  0x0000-0xffff]
	[    3.072006] bus: 00 [mem 0xc8000000-0xcfffffff]
	[    3.072007] bus: 00 [mem 0xd0000000-0xdfffffff]
	[    3.072008] bus: 00 [mem 0xf0000000-0xffffffff]
	[    3.072009] bus: 00 [mem 0x838000000-0xfcffffffff]
	[    3.076097] ACPI: bus type PCI registered
	[    3.080008] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
	[    3.084163] PCI: MMCONFIG for domain 0000 [bus 00-02] at [mem 0xe0000000-0xe02fffff] (base 0xe0000000)
	[    3.096006] PCI: MMCONFIG at [mem 0xe0000000-0xe02fffff] reserved in E820
	[    3.100022] PCI: Using configuration type 1 for base access
...
	[    3.257874] PCI host bridge to bus 0000:00
	[    3.264005] pci_bus 0000:00: root bus resource [io  0x03b0-0x03df window]
	[    3.268003] pci_bus 0000:00: root bus resource [io  0x0d00-0x3fff window]
	[    3.276003] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window]
	[    3.284003] pci_bus 0000:00: root bus resource [mem 0xd0000000-0xd7ffffff window]
	[    3.292003] pci_bus 0000:00: root bus resource [mem 0xc8000000-0xce0fffff window]
	[    3.300003] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000cafff window]
	[    3.308003] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed45000 window]
	[    3.316003] pci_bus 0000:00: root bus resource [io  0x0000-0x03af window]
	[    3.320003] pci_bus 0000:00: root bus resource [io  0x03e0-0x0cf7 window]
	[    3.328004] pci_bus 0000:00: root bus resource [bus 00-bf]
	[    3.336013] pci 0000:00:00.0: [1002:5a10] type 00 class 0x060000
	[    3.336197] pci 0000:00:04.0: [1002:5a18] type 01 class 0x060400
	[    3.336215] pci 0000:00:04.0: enabling Extended Tags
	[    3.340027] pci 0000:00:04.0: PME# supported from D0 D3hot D3cold
	[    3.340222] pci 0000:00:11.0: [1002:4390] type 00 class 0x01018f
	[    3.340244] pci 0000:00:11.0: reg 0x10: [io  0x2430-0x2437]
	[    3.340253] pci 0000:00:11.0: reg 0x14: [io  0x2424-0x2427]
	[    3.340262] pci 0000:00:11.0: reg 0x18: [io  0x2428-0x242f]
	[    3.340271] pci 0000:00:11.0: reg 0x1c: [io  0x2420-0x2423]
	[    3.340280] pci 0000:00:11.0: reg 0x20: [io  0x2400-0x240f]
	[    3.340289] pci 0000:00:11.0: reg 0x24: [mem 0xc8014000-0xc80143ff]
	[    3.340314] pci 0000:00:11.0: set SATA to AHCI mode
	[    3.344192] pci 0000:00:12.0: [1002:4397] type 00 class 0x0c0310
	[    3.344210] pci 0000:00:12.0: reg 0x10: [mem 0xc8015000-0xc8015fff]
	[    3.344431] pci 0000:00:12.1: [1002:4398] type 00 class 0x0c0310
	[    3.344449] pci 0000:00:12.1: reg 0x10: [mem 0xc8016000-0xc8016fff]
	[    3.344674] pci 0000:00:12.2: [1002:4396] type 00 class 0x0c0320
	[    3.344695] pci 0000:00:12.2: reg 0x10: [mem 0xc8014400-0xc80144ff]
	[    3.344773] pci 0000:00:12.2: supports D1 D2
	[    3.344775] pci 0000:00:12.2: PME# supported from D0 D1 D2 D3hot
	[    3.344949] pci 0000:00:13.0: [1002:4397] type 00 class 0x0c0310
	[    3.344967] pci 0000:00:13.0: reg 0x10: [mem 0xc8017000-0xc8017fff]
	[    3.345186] pci 0000:00:13.1: [1002:4398] type 00 class 0x0c0310
	[    3.345204] pci 0000:00:13.1: reg 0x10: [mem 0xc8018000-0xc8018fff]
	[    3.345425] pci 0000:00:13.2: [1002:4396] type 00 class 0x0c0320
	[    3.345446] pci 0000:00:13.2: reg 0x10: [mem 0xc8014800-0xc80148ff]
	[    3.345525] pci 0000:00:13.2: supports D1 D2
	[    3.345527] pci 0000:00:13.2: PME# supported from D0 D1 D2 D3hot
	[    3.345701] pci 0000:00:14.0: [1002:4385] type 00 class 0x0c0500
	[    3.345948] pci 0000:00:14.1: [1002:439c] type 00 class 0x01018a
	[    3.345968] pci 0000:00:14.1: reg 0x10: [io  0x01f0-0x01f7]
	[    3.345977] pci 0000:00:14.1: reg 0x14: [io  0x03f4-0x03f7]
	[    3.345987] pci 0000:00:14.1: reg 0x18: [io  0x0170-0x0177]
	[    3.345995] pci 0000:00:14.1: reg 0x1c: [io  0x0374-0x0377]
	[    3.346004] pci 0000:00:14.1: reg 0x20: [io  0x2410-0x241f]
	[    3.346024] pci 0000:00:14.1: legacy IDE quirk: reg 0x10: [io  0x01f0-0x01f7]
	[    3.352003] pci 0000:00:14.1: legacy IDE quirk: reg 0x14: [io  0x03f6]
	[    3.360003] pci 0000:00:14.1: legacy IDE quirk: reg 0x18: [io  0x0170-0x0177]
	[    3.368002] pci 0000:00:14.1: legacy IDE quirk: reg 0x1c: [io  0x0376]
	[    3.376185] pci 0000:00:14.3: [1002:439d] type 00 class 0x060100
	[    3.376412] pci 0000:00:14.4: [1002:4384] type 01 class 0x060401
	[    3.376619] pci 0000:00:14.5: [1002:4399] type 00 class 0x0c0310
	[    3.376637] pci 0000:00:14.5: reg 0x10: [mem 0xc8019000-0xc8019fff]
	[    3.376859] pci 0000:00:18.0: [1022:1200] type 00 class 0x060000
	[    3.377000] pci 0000:00:18.1: [1022:1201] type 00 class 0x060000
	[    3.377122] pci 0000:00:18.2: [1022:1202] type 00 class 0x060000
	[    3.377247] pci 0000:00:18.3: [1022:1203] type 00 class 0x060000
	[    3.377373] pci 0000:00:18.4: [1022:1204] type 00 class 0x060000
	[    3.377373] pci 0000:00:19.0: [1022:1200] type 00 class 0x060000
	[    3.377373] pci 0000:00:19.1: [1022:1201] type 00 class 0x060000
	[    3.377373] pci 0000:00:19.2: [1022:1202] type 00 class 0x060000
	[    3.377373] pci 0000:00:19.3: [1022:1203] type 00 class 0x060000
	[    3.377373] pci 0000:00:19.4: [1022:1204] type 00 class 0x060000
	[    3.377373] pci 0000:00:1a.0: [1022:1200] type 00 class 0x060000
	[    3.377373] pci 0000:00:1a.1: [1022:1201] type 00 class 0x060000
	[    3.377373] pci 0000:00:1a.2: [1022:1202] type 00 class 0x060000
	[    3.377373] pci 0000:00:1a.3: [1022:1203] type 00 class 0x060000
	[    3.377373] pci 0000:00:1a.4: [1022:1204] type 00 class 0x060000
	[    3.377373] pci 0000:00:1b.0: [1022:1200] type 00 class 0x060000
	[    3.377457] pci 0000:00:1b.1: [1022:1201] type 00 class 0x060000
	[    3.377584] pci 0000:00:1b.2: [1022:1202] type 00 class 0x060000
	[    3.377709] pci 0000:00:1b.3: [1022:1203] type 00 class 0x060000
	[    3.377843] pci 0000:00:1b.4: [1022:1204] type 00 class 0x060000
	[    3.378063] pci 0000:01:00.0: [14e4:1639] type 00 class 0x020000
	[    3.378120] pci 0000:01:00.0: reg 0x10: [mem 0xca000000-0xcbffffff 64bit]
	[    3.378148] pci 0000:01:00.0: reg 0x30: [mem 0x00000000-0x0001ffff pref]
	[    3.378208] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
	[    3.378287] pci 0000:01:00.1: [14e4:1639] type 00 class 0x020000
	[    3.378307] pci 0000:01:00.1: reg 0x10: [mem 0xcc000000-0xcdffffff 64bit]
	[    3.378335] pci 0000:01:00.1: reg 0x30: [mem 0x00000000-0x0001ffff pref]
	[    3.378394] pci 0000:01:00.1: PME# supported from D0 D3hot D3cold
	[    3.392042] pci 0000:00:04.0: PCI bridge to [bus 01]
	[    3.396007] pci 0000:00:04.0:   bridge window [mem 0xca000000-0xcdffffff]
	[    3.396089] pci 0000:02:06.0: [1002:515e] type 00 class 0x030000
	[    3.396116] pci 0000:02:06.0: reg 0x10: [mem 0xd0000000-0xd7ffffff pref]
	[    3.396128] pci 0000:02:06.0: reg 0x14: [io  0x3000-0x30ff]
	[    3.396140] pci 0000:02:06.0: reg 0x18: [mem 0xce000000-0xce00ffff]
	[    3.396183] pci 0000:02:06.0: reg 0x30: [mem 0x00000000-0x0001ffff pref]
	[    3.396235] pci 0000:02:06.0: supports D1 D2
	[    3.396360] pci 0000:00:14.4: PCI bridge to [bus 02] (subtractive decode)
	[    3.404006] pci 0000:00:14.4:   bridge window [io  0x3000-0x3fff]
	[    3.404010] pci 0000:00:14.4:   bridge window [mem 0xce000000-0xce0fffff]
	[    3.404014] pci 0000:00:14.4:   bridge window [mem 0xd0000000-0xd7ffffff pref]
	[    3.404017] pci 0000:00:14.4:   bridge window [io  0x03b0-0x03df window] (subtractive decode)
	[    3.404019] pci 0000:00:14.4:   bridge window [io  0x0d00-0x3fff window] (subtractive decode)
	[    3.404021] pci 0000:00:14.4:   bridge window [mem 0x000a0000-0x000bffff window] (subtractive decode)
	[    3.404023] pci 0000:00:14.4:   bridge window [mem 0xd0000000-0xd7ffffff window] (subtractive decode)
	[    3.404025] pci 0000:00:14.4:   bridge window [mem 0xc8000000-0xce0fffff window] (subtractive decode)
	[    3.404026] pci 0000:00:14.4:   bridge window [mem 0x000c0000-0x000cafff window] (subtractive decode)
	[    3.404028] pci 0000:00:14.4:   bridge window [mem 0xfed40000-0xfed45000 window] (subtractive decode)
	[    3.404030] pci 0000:00:14.4:   bridge window [io  0x0000-0x03af window] (subtractive decode)
	[    3.404032] pci 0000:00:14.4:   bridge window [io  0x03e0-0x0cf7 window] (subtractive decode)
...
	[    3.672074] e820: reserve RAM buffer [mem 0x0009d800-0x0009ffff]
	[    3.672077] e820: reserve RAM buffer [mem 0xc7e80000-0xc7ffffff]
...
	[    3.751327] system 00:00: [mem 0xe0000000-0xefffffff] has been reserved
	[    3.758121] system 00:00: [mem 0xfec00000-0xfec00fff] could not be reserved
	[    3.765226] system 00:00: [mem 0xfee00000-0xfee00fff] has been reserved
	[    3.771982] system 00:00: [mem 0xc8000000-0xc8007fff] could not be reserved
	[    3.779098] system 00:00: Plug and Play ACPI device, IDs PNP0c02 (active)
	[    3.780205] pnp 00:01: Plug and Play ACPI device, IDs PNP0b00 (active)
	[    3.780262] pnp 00:02: Plug and Play ACPI device, IDs PNP0303 (active)
	[    3.780310] pnp 00:03: Plug and Play ACPI device, IDs PNP0f13 (active)
	[    3.780426] system 00:04: [io  0x0220-0x022f] has been reserved
	[    3.790998] system 00:04: [io  0x040b] has been reserved
	[    3.796453] system 00:04: [io  0x04d0-0x04d1] has been reserved
	[    3.802514] system 00:04: [io  0x04d6] has been reserved
	[    3.807968] system 00:04: [io  0x0530-0x0537] has been reserved
	[    3.814030] system 00:04: [io  0x0c00-0x0c01] has been reserved
	[    3.820093] system 00:04: [io  0x0c14] has been reserved
	[    3.825548] system 00:04: [io  0x0c50-0x0c52] has been reserved
	[    3.831610] system 00:04: [io  0x0c6c] has been reserved
	[    3.837065] system 00:04: [io  0x0c6f] has been reserved
	[    3.842542] system 00:04: [io  0x0ca0-0x0caf] has been reserved
	[    3.848604] system 00:04: [io  0x0cd0-0x0cd1] has been reserved
	[    3.854667] system 00:04: [io  0x0cd2-0x0cd3] has been reserved
	[    3.860730] system 00:04: [io  0x0cd4-0x0cd5] has been reserved
	[    3.866793] system 00:04: [io  0x0cd6-0x0cd7] has been reserved
	[    3.872856] system 00:04: [io  0x0cd8-0x0cdf] has been reserved
	[    3.878918] system 00:04: [io  0x2000-0x205f] has been reserved
	[    3.884981] system 00:04: [io  0x2100-0x21ff window] has been reserved
	[    3.891650] system 00:04: [io  0x2200-0x22ff window] has been reserved
	[    3.898321] system 00:04: [io  0x0f40-0x0f47] has been reserved
	[    3.904383] system 00:04: [io  0x087f] has been reserved
	[    3.909844] system 00:04: Plug and Play ACPI device, IDs PNP0c02 (active)
	[    3.910055] system 00:05: [mem 0x000e0000-0x000fffff] could not be reserved
	[    3.917194] system 00:05: [mem 0xfff00000-0xffffffff] has been reserved
	[    3.923950] system 00:05: [mem 0xfec10000-0xfec1001f] has been reserved
	[    3.930710] system 00:05: Plug and Play ACPI device, IDs PNP0c01 (active)
	[    3.931208] pnp 00:06: Plug and Play ACPI device, IDs PNP0501 (active)
	[    3.931939] pnp: PnP ACPI: found 7 devices
	[    3.953364] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
	[    3.962499] pci 0000:01:00.0: BAR 6: no space for [mem size 0x00020000 pref]
	[    3.969693] pci 0000:01:00.0: BAR 6: failed to assign [mem size 0x00020000 pref]
	[    3.977318] pci 0000:01:00.1: BAR 6: no space for [mem size 0x00020000 pref]
	[    3.984507] pci 0000:01:00.1: BAR 6: failed to assign [mem size 0x00020000 pref]
	[    3.992134] pci 0000:00:04.0: PCI bridge to [bus 01]
	[    3.997243] pci 0000:00:04.0:   bridge window [mem 0xca000000-0xcdffffff]
	[    4.004181] pci 0000:02:06.0: BAR 6: assigned [mem 0xce020000-0xce03ffff pref]
	[    4.011634] pci 0000:00:14.4: PCI bridge to [bus 02]
	[    4.016743] pci 0000:00:14.4:   bridge window [io  0x3000-0x3fff]
	[    4.022982] pci 0000:00:14.4:   bridge window [mem 0xce000000-0xce0fffff]
	[    4.029915] pci 0000:00:14.4:   bridge window [mem 0xd0000000-0xd7ffffff pref]
	[    4.037375] pci_bus 0000:00: resource 4 [io  0x03b0-0x03df window]
	[    4.037377] pci_bus 0000:00: resource 5 [io  0x0d00-0x3fff window]
	[    4.037379] pci_bus 0000:00: resource 6 [mem 0x000a0000-0x000bffff window]
	[    4.037380] pci_bus 0000:00: resource 7 [mem 0xd0000000-0xd7ffffff window]
	[    4.037382] pci_bus 0000:00: resource 8 [mem 0xc8000000-0xce0fffff window]
	[    4.037384] pci_bus 0000:00: resource 9 [mem 0x000c0000-0x000cafff window]
	[    4.037386] pci_bus 0000:00: resource 10 [mem 0xfed40000-0xfed45000 window]
	[    4.037388] pci_bus 0000:00: resource 11 [io  0x0000-0x03af window]
	[    4.037390] pci_bus 0000:00: resource 12 [io  0x03e0-0x0cf7 window]
	[    4.037392] pci_bus 0000:01: resource 1 [mem 0xca000000-0xcdffffff]
	[    4.037394] pci_bus 0000:02: resource 0 [io  0x3000-0x3fff]
	[    4.037396] pci_bus 0000:02: resource 1 [mem 0xce000000-0xce0fffff]
	[    4.037398] pci_bus 0000:02: resource 2 [mem 0xd0000000-0xd7ffffff pref]
	[    4.037400] pci_bus 0000:02: resource 4 [io  0x03b0-0x03df window]
	[    4.037401] pci_bus 0000:02: resource 5 [io  0x0d00-0x3fff window]
	[    4.037403] pci_bus 0000:02: resource 6 [mem 0x000a0000-0x000bffff window]
	[    4.037405] pci_bus 0000:02: resource 7 [mem 0xd0000000-0xd7ffffff window]
	[    4.037406] pci_bus 0000:02: resource 8 [mem 0xc8000000-0xce0fffff window]
	[    4.037408] pci_bus 0000:02: resource 9 [mem 0x000c0000-0x000cafff window]
	[    4.037410] pci_bus 0000:02: resource 10 [mem 0xfed40000-0xfed45000 window]
	[    4.037412] pci_bus 0000:02: resource 11 [io  0x0000-0x03af window]
	[    4.037413] pci_bus 0000:02: resource 12 [io  0x03e0-0x0cf7 window]
...
	[    4.088124] pci 0000:02:06.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]
	[    4.096709] PCI: CLS 32 bytes, default 64
	[    4.096791] Unpacking initramfs...
	[    7.106451] Freeing initrd memory: 22376K
	[    7.113357] PCI-DMA: Disabling AGP.
	[    7.117189] PCI-DMA: aperture base @ b8000000 size 65536 KB
	[    7.122931] PCI-DMA: using GART IOMMU.
	[    7.126826] PCI-DMA: Reserving 64MB of IOMMU area in the AGP aperture
	[    7.137697] __memblock_free_late: [0x000000c7e78000-0x000000c7e7ffff] swiotlb_free+0xc0/0x188
	[    7.146503] __memblock_free_late: [0x00000837e66000-0x00000837ea5fff] swiotlb_free+0x106/0x188
	[    7.155355] __memblock_free_late: [0x00000837ea6000-0x00000837ec5fff] swiotlb_free+0x14c/0x188
	[    7.164201] __memblock_free_late: [0x000000bf000000-0x000000c2ffffff] swiotlb_free+0x171/0x188
...
	[    9.218654] resource sanity check: requesting [mem 0x000c0000-0x000dffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000cafff window]
	[    9.218661] caller pci_map_rom+0x58/0xe0 mapping multiple BARs
	[    9.218773] radeon 0000:02:06.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (32M used)
	[    9.218775] radeon 0000:02:06.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
	[    9.218784] [drm] Detected VRAM RAM=128M, BAR=128M
	[    9.218785] [drm] RAM width 16bits DDR
	[    9.218905] [TTM] Zone  kernel: Available graphics memory: 16381524 kiB
	[    9.218906] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
	[    9.218907] [TTM] Initializing pool allocator
	[    9.218914] [TTM] Initializing DMA pool allocator
	[    9.218948] [drm] radeon: 32M of VRAM memory ready
	[    9.218949] [drm] radeon: 512M of GTT memory ready.
	[    9.218962] [drm] GART: num cpu pages 131072, num gpu pages 131072
	[    9.253710] [drm] PCI GART of 512M enabled (table at 0x00000000C2880000).
	[    9.253734] radeon 0000:02:06.0: WB disabled
	[    9.253739] radeon 0000:02:06.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff91558280f000
	[    9.253742] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
	[    9.253742] [drm] Driver supports precise vblank timestamp query.
	[    9.253790] [drm] radeon: irq initialized.
	[    9.253802] [drm] Loading R100 Microcode
	[    9.253826] radeon 0000:02:06.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
	[    9.253828] radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
	[    9.253919] [drm:r100_cp_init [radeon]] *ERROR* Failed to load firmware!
	[    9.253921] radeon 0000:02:06.0: failed initializing CP (-2).
	[    9.253923] radeon 0000:02:06.0: Disabling GPU acceleration
...
	[    9.253929] [drm] radeon: cp finalized
	[    9.255032] [drm] No TV DAC info found in BIOS
	[    9.255079] [drm] Radeon Display Connectors
	[    9.255080] [drm] Connector 0:
	[    9.255081] [drm]   VGA-1
	[    9.255083] [drm]   DDC: 0x60 0x60 0x60 0x60 0x60 0x60 0x60 0x60
	[    9.255083] [drm]   Encoders:
	[    9.255084] [drm]     CRT1: INTERNAL_DAC1
	[    9.255086] [drm] Connector 1:
	[    9.255086] [drm]   DVI-I-1
	[    9.255087] [drm]   HPD2
	[    9.255089] [drm]   DDC: 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c 0x6c
	[    9.255089] [drm]   Encoders:
	[    9.255090] [drm]     CRT2: INTERNAL_DAC2
	[    9.255091] [drm]     DFP2: INTERNAL_DVO1
	[    9.398386] [drm] fb mappable at 0xD0040000
	[    9.398387] [drm] vram apper at 0xD0000000
	[    9.398388] [drm] size 1572864
	[    9.398388] [drm] fb depth is 16
	[    9.398389] [drm]    pitch is 2048

/proc/iomem:
	00000000-00000fff : Reserved
	00001000-0009d7ff : System RAM
	0009d800-0009ffff : Reserved
	000a0000-000bffff : PCI Bus 0000:00
	000c0000-000cafff : PCI Bus 0000:00
	  000c0000-000cafff : Video ROM
	000cb000-000ccfff : Adapter ROM
	000ce000-000fffff : Reserved
	  000f0000-000fffff : System ROM
	00100000-c7e7ffff : System RAM
	  0b000000-0b792eb5 : Kernel code
	  0b792eb6-0bd5d47f : Kernel data
	  0c274000-0c3c8fff : Kernel bss
	  b7000000-c6ffffff : Crash kernel
	c7e80000-c7e8afff : ACPI Tables
	c7e8b000-c7e8cfff : ACPI Non-volatile Storage
	c7e8d000-c7ffffff : Reserved
	c8000000-ce0fffff : PCI Bus 0000:00
	  c8000000-c80003ff : IOAPIC 1
	  c8014000-c80143ff : 0000:00:11.0
	    c8014000-c80143ff : ahci
	  c8014400-c80144ff : 0000:00:12.2
	    c8014400-c80144ff : ehci_hcd
	  c8014800-c80148ff : 0000:00:13.2
	    c8014800-c80148ff : ehci_hcd
	  c8015000-c8015fff : 0000:00:12.0
	    c8015000-c8015fff : ohci_hcd
	  c8016000-c8016fff : 0000:00:12.1
	    c8016000-c8016fff : ohci_hcd
	  c8017000-c8017fff : 0000:00:13.0
	    c8017000-c8017fff : ohci_hcd
	  c8018000-c8018fff : 0000:00:13.1
	    c8018000-c8018fff : ohci_hcd
	  c8019000-c8019fff : 0000:00:14.5
	    c8019000-c8019fff : ohci_hcd
	  ca000000-cdffffff : PCI Bus 0000:01
	    ca000000-cbffffff : 0000:01:00.0
	      ca000000-cbffffff : bnx2
	    cc000000-cdffffff : 0000:01:00.1
	      cc000000-cdffffff : bnx2
	  ce000000-ce0fffff : PCI Bus 0000:02
	    ce000000-ce00ffff : 0000:02:06.0
	d0000000-d7ffffff : PCI Bus 0000:00
	  d0000000-d7ffffff : PCI Bus 0000:02
	    d0000000-d7ffffff : 0000:02:06.0
	e0000000-efffffff : Reserved
	  e0000000-efffffff : pnp 00:00
	    e0000000-e02fffff : PCI MMCONFIG 0000 [bus 00-02]
	fec00000-fec0ffff : Reserved
	  fec00000-fec003ff : IOAPIC 0
	fec10000-fec1001f : pnp 00:05
	fed00000-fed003ff : HPET 2
	  fed00000-fed003ff : PNP0103:00
	fed40000-fed45000 : PCI Bus 0000:00
	fee00000-fee00fff : Local APIC
	  fee00000-fee00fff : Reserved
	    fee00000-fee00fff : pnp 00:00
	fff00000-ffffffff : Reserved
	  fff00000-ffffffff : pnp 00:05
	100000000-837ffffff : System RAM
	  831000000-8374fffff : Crash kernel

Without the patch, the machine hangs as soon as I touch one of the first 10
pages of /proc/vmcore that are mapped to the GART region. (On a different
mechine, this caused a strange MCE and reboot.)

With the patch, I was able to read the full /proc/vmcore.
I manually verified the ELF header of /proc/vmcore and the patch works as intended
(the section containing the GART region hsa been split in two to exclude GART).

> If this patch works, then I am wondering how we shold deal with the old
> way in which no '-s' is specified. Since no GART information is exported
> to /proc/iomem.
> 
> Do we have a way to pick GART region away from iomem_resource to not let
> the aperture seen from /proc/iomem?

I haven't given this any thought yet. I can look at it later...

Thanks,

-- 
Jiri Bohac <jbohac at suse.cz>
SUSE Labs, Prague, Czechia



From bhsharma at redhat.com  Mon Nov 13 00:49:54 2017
From: bhsharma at redhat.com (Bhupesh Sharma)
Date: Mon, 13 Nov 2017 14:19:54 +0530
Subject: [PATCH] kdump: print a message in case crashkernel size parsing
 resulted in zero bytes
In-Reply-To: <20171113054311.GA4971@dhcp-128-65.nay.redhat.com>
References: <20171113054311.GA4971@dhcp-128-65.nay.redhat.com>
Message-ID: <a8a5d2ae-579e-262c-4231-49ab967b0108@redhat.com>

Hi Dave,

Cc: arm kernel mailing list for wider distribution

On 11/13/2017 11:13 AM, Dave Young wrote:
> In parse_crashkernel_mem, it silently return in case we get zero
> bytes in the parsing function.  It is useful for debugging for
> adding a warning message especially sometimes kernel can not boot
> up correctly.
>
> Signed-off-by: Dave Young <dyoung at redhat.com>
> ---
>  kernel/crash_core.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- linux-x86.orig/kernel/crash_core.c
> +++ linux-x86/kernel/crash_core.c
> @@ -108,7 +108,8 @@ static int __init parse_crashkernel_mem(
>                  return -EINVAL;
>              }
>          }
> -    }
> +    } else
> +        pr_warn("crashkernel size resulted in zero bytes\n");
>
>      return 0;
>  }
>
This is a useful change as finding this debug message in the boot logs allows better debug of crashkernel related issues.

However I have one minor point:

- The comment above 'parse_crashkernel_mem' currently mentions:
  * The function returns 0 on success and -EINVAL on failure.
  */

- I am wondering if we hit the WARNING case where the crashkernel size resulted in 0 bytes, then should we still be returning 0 from this function. Or, should this be replaced with 'return -EINVAL'.

- If not, can we atleast update the comment above this function to better document the return values and where having a 'return 0' should be ok, even if crashkernel size resulted in 0 bytes.

Regards,
Bhupesh


From ats-kumagai at wm.jp.nec.com  Mon Nov 13 01:14:29 2017
From: ats-kumagai at wm.jp.nec.com (Atsushi Kumagai)
Date: Mon, 13 Nov 2017 09:14:29 +0000
Subject: [makedumpfile PATCH] ppc64: update hash page table geometry
In-Reply-To: <151033402186.13486.3228487082738293986.stgit@hbathini.in.ibm.com>
References: <151033402186.13486.3228487082738293986.stgit@hbathini.in.ibm.com>
Message-ID: <0910DD04CBD6DE4193FCF86B9C00BE9701F248FB@BPXM01GP.gisp.nec.co.jp>

Hello Hari,

>Starting with kernel 4.12, BOOK3S hash page table geometry is updated
>to accommodate larger virtual address range. Update here accordingly.
>
>Signed-off-by: Hari Bathini <hbathini at linux.vnet.ibm.com>

Thanks, I'll merge this patch into v1.6.3.

Regards
Atsushi Kumagai

>---
> arch/ppc64.c   |   12 +++++++++---
> makedumpfile.h |    3 +++
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
>diff --git a/arch/ppc64.c b/arch/ppc64.c
>index 2f5a0da..8bdbcc5 100644
>--- a/arch/ppc64.c
>+++ b/arch/ppc64.c
>@@ -245,10 +245,16 @@ ppc64_vmalloc_init(void)
>
> 		} else if (info->kernel_version >= KERNEL_VERSION(4, 6, 0)) {
> 			info->l1_index_size = PTE_INDEX_SIZE_L4_64K_3_10;
>-			info->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_6;
>-			info->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_6;
>-			info->l4_index_size = PGD_INDEX_SIZE_L4_64K_3_10;
>
>+			if (info->kernel_version >= KERNEL_VERSION(4, 12, 0)) {
>+				info->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_12;
>+				info->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_12;
>+				info->l4_index_size = PGD_INDEX_SIZE_L4_64K_4_12;
>+			} else {
>+				info->l2_index_size = PMD_INDEX_SIZE_L4_64K_4_6;
>+				info->l3_index_size = PUD_INDEX_SIZE_L4_64K_4_6;
>+				info->l4_index_size = PGD_INDEX_SIZE_L4_64K_3_10;
>+			}
> 		} else if (info->kernel_version >= KERNEL_VERSION(3, 10, 0)) {
> 			info->l1_index_size = PTE_INDEX_SIZE_L4_64K_3_10;
> 			info->l2_index_size = PMD_INDEX_SIZE_L4_64K_3_10;
>diff --git a/makedumpfile.h b/makedumpfile.h
>index db75379..b983aaf 100644
>--- a/makedumpfile.h
>+++ b/makedumpfile.h
>@@ -670,6 +670,9 @@ unsigned long get_kvbase_arm64(void);
> #define PGD_INDEX_SIZE_L4_64K_3_10  12
> #define PMD_INDEX_SIZE_L4_64K_4_6  5
> #define PUD_INDEX_SIZE_L4_64K_4_6  5
>+#define PMD_INDEX_SIZE_L4_64K_4_12 10
>+#define PUD_INDEX_SIZE_L4_64K_4_12 7
>+#define PGD_INDEX_SIZE_L4_64K_4_12 8
> #define PTE_INDEX_SIZE_RADIX_64K  5
> #define PMD_INDEX_SIZE_RADIX_64K  9
> #define PUD_INDEX_SIZE_RADIX_64K  9

From philliphadzi2 at gmail.com  Mon Nov 13 06:44:53 2017
From: philliphadzi2 at gmail.com (Amos Kalonzo)
Date: Mon, 13 Nov 2017 15:44:53 +0100
Subject: No subject
Message-ID: <CANXwH3_v=L9wqhU0MShz=LsAoaks+NCxoAwqfK37qjVXQJ378A@mail.gmail.com>

Attn:

I am wondering why You haven't respond to my email for some days now.
reference to my client's contract balance payment of (11.7M,USD)
Kindly get back to me for more details.

Best Regards

Amos Kalonzo


From dyoung at redhat.com  Mon Nov 13 22:39:55 2017
From: dyoung at redhat.com (Dave Young)
Date: Tue, 14 Nov 2017 14:39:55 +0800
Subject: [PATCH v6 4/5] crash: export paddr_vmcoreinfo_note()
In-Reply-To: <20171113192958.22953-5-marcandre.lureau@redhat.com>
References: <20171113192958.22953-1-marcandre.lureau@redhat.com>
 <20171113192958.22953-5-marcandre.lureau@redhat.com>
Message-ID: <20171114063955.GA4668@dhcp-128-65.nay.redhat.com>

On 11/13/17 at 08:29pm, Marc-Andr? Lureau wrote:
> The following patch is going to use the symbol from the fw_cfg module,
> to call the function and write the note location details in the
> vmcoreinfo entry, so qemu can produce dumps with the vmcoreinfo note.
> 
> CC: Andrew Morton <akpm at linux-foundation.org>
> CC: Baoquan He <bhe at redhat.com>
> CC: Dave Young <dyoung at redhat.com>
> CC: Dave Young <dyoung at redhat.com>
> CC: Hari Bathini <hbathini at linux.vnet.ibm.com>
> CC: Tony Luck <tony.luck at intel.com>
> CC: Vivek Goyal <vgoyal at redhat.com>
> Signed-off-by: Marc-Andr? Lureau <marcandre.lureau at redhat.com>
> Acked-by: Gabriel Somlo <somlo at cmu.edu>
> ---
>  kernel/crash_core.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> index 6db80fc0810b..47541c891810 100644
> --- a/kernel/crash_core.c
> +++ b/kernel/crash_core.c
> @@ -375,6 +375,7 @@ phys_addr_t __weak paddr_vmcoreinfo_note(void)
>  {
>  	return __pa(vmcoreinfo_note);
>  }
> +EXPORT_SYMBOL(paddr_vmcoreinfo_note);
>  
>  static int __init crash_save_vmcoreinfo_init(void)
>  {
> -- 
> 2.15.0.125.g8f49766d64
> 

Acked-by: Dave Young <dyoung at redhat.com>

Thanks
Dave


From dyoung at redhat.com  Tue Nov 14 00:01:29 2017
From: dyoung at redhat.com (Dave Young)
Date: Tue, 14 Nov 2017 16:01:29 +0800
Subject: [PATCH V2] kdump: print a message in case parse_crashkernel_mem
 resulted in zero bytes
Message-ID: <20171114080129.GA6115@dhcp-128-65.nay.redhat.com>

In parse_crashkernel_mem, it silently return in case we get zero
bytes in the parsing function.  It is useful for debugging for
adding a message especially sometimes kernel can not boot
up correctly.

Add a pr_info instead of pr_warn because it is expected behavior for
size = 0, eg. crashkernel=2G-4G:128M, size will be 0 in case system
memory is less than 2G.

Signed-off-by: Dave Young <dyoung at redhat.com>
---
[v1 -> v2]: bhsharma: pr_warn looks confusing because of return 0
 kernel/crash_core.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-x86.orig/kernel/crash_core.c
+++ linux-x86/kernel/crash_core.c
@@ -108,7 +108,8 @@ static int __init parse_crashkernel_mem(
 				return -EINVAL;
 			}
 		}
-	}
+	} else
+		pr_info("crashkernel size resulted in zero bytes\n");
 
 	return 0;
 }


From bhe at redhat.com  Tue Nov 14 21:47:42 2017
From: bhe at redhat.com (Baoquan He)
Date: Wed, 15 Nov 2017 13:47:42 +0800
Subject: [PATCH 2/3] X86/kdump: crashkernel=X try to reserve below 896M
 first then below 4G and MAXMEM
In-Reply-To: <20171024053901.757504190@redhat.com>
References: <20171024053901.757504190@redhat.com>
Message-ID: <20171115054742.GL10474@x1>

Hi Dave,

Thanks for your effort to push this into upstream. While I have one
concern, please see the inline comments.

On 10/24/17 at 01:31pm, Dave Young wrote:
> Now crashkernel=X will fail if there's not enough memory at low region
> (below 896M) when trying to reserve large memory size.  One can use
> crashkernel=xM,high to reserve it at high region (>4G) but it is more
> convinient to improve crashkernel=X to: 
> 
>  - First try to reserve X below 896M (for being compatible with old
>    kexec-tools).
>  - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
>  - If fails, try to reserve X from MAXMEM top down.
> 
> It's more transparent and user-friendly.
> 
> If crashkernel is large and the reserved is beyond 896M, old kexec-tools
> is not compatible with new kernel because old kexec-tools can not load
> kernel at high memory region, there was an old discussion below:
> https://lkml.org/lkml/2013/10/15/601
> 
> But actually the behavior is consistent during my test. Suppose
> old kernel fail to reserve memory at low areas, kdump does not
> work because no meory reserved. With this patch, suppose new kernel
> successfully reserved memory at high areas, old kexec-tools still fail
> to load kdump kernel (tested 2.0.2), so it is acceptable, no need to
> worry about the compatibility.
> 
> Here is the test result (kexec-tools 2.0.2, no high memory load
> support):
> Crashkernel over 4G:
> # cat /proc/iomem|grep Crash
>   be000000-cdffffff : Crash kernel
>   213000000-21effffff : Crash kernel
> # ./kexec  -p /boot/vmlinuz-`uname -r`
> Memory for crashkernel is not reserved
> Please reserve memory by passing "crashkernel=X at Y" parameter to the kernel
> Then try loading kdump kernel
> 
> crashkernel: 896M-4G:
> # cat /proc/iomem|grep Crash
>   96000000-cdefffff : Crash kernel
> # ./kexec -p /boot/vmlinuz-4.14.0-rc4+
> ELF core (kcore) parse failed
> Cannot load /boot/vmlinuz-4.14.0-rc4+
> 
> Signed-off-by: Dave Young <dyoung at redhat.com>
> ---
>  arch/x86/kernel/setup.c |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> --- linux-x86.orig/arch/x86/kernel/setup.c
> +++ linux-x86/arch/x86/kernel/setup.c
> @@ -568,6 +568,22 @@ static void __init reserve_crashkernel(v
>  						    high ? CRASH_ADDR_HIGH_MAX
>  							 : CRASH_ADDR_LOW_MAX,
>  						    crash_size, CRASH_ALIGN);
> +#ifdef CONFIG_X86_64
> +		/*
> +		 * crashkernel=X reserve below 896M fails? Try below 4G
> +		 */
> +		if (!high && !crash_base)
> +			crash_base = memblock_find_in_range(CRASH_ALIGN,
> +						(1ULL << 32),
> +						crash_size, CRASH_ALIGN);
> +		/*
> +		 * crashkernel=X reserve below 4G fails? Try MAXMEM
> +		 */
> +		if (!high && !crash_base)
> +			crash_base = memblock_find_in_range(CRASH_ALIGN,
> +						CRASH_ADDR_HIGH_MAX,
> +						crash_size, CRASH_ALIGN);

For kdump, most of systems are x86 64. If both Yinghai and Vivek have no
objection to search an available region of crash_size above 896M
naturely, why don't we search it with function
__memblock_find_range_bottom_up(). It can search from below 896M to
above 4G, almost the same as the change you have made currently. Mainly
the code will be much simpler.

The several times of searching looks not good and a little confusing.

What do you think?

Thanks
Baoquan

> +#endif
>  		if (!crash_base) {
>  			pr_info("crashkernel reservation failed - No suitable area found.\n");
>  			return;
> 
> 


From dyoung at redhat.com  Tue Nov 14 22:56:23 2017
From: dyoung at redhat.com (Dave Young)
Date: Wed, 15 Nov 2017 14:56:23 +0800
Subject: [PATCH 2/3] X86/kdump: crashkernel=X try to reserve below 896M
 first then below 4G and MAXMEM
In-Reply-To: <20171115054742.GL10474@x1>
References: <20171024053901.757504190@redhat.com> <20171115054742.GL10474@x1>
Message-ID: <20171115065623.GA5192@dhcp-128-65.nay.redhat.com>

On 11/15/17 at 01:47pm, Baoquan He wrote:
> Hi Dave,
> 
> Thanks for your effort to push this into upstream. While I have one
> concern, please see the inline comments.
> 
> On 10/24/17 at 01:31pm, Dave Young wrote:
> > Now crashkernel=X will fail if there's not enough memory at low region
> > (below 896M) when trying to reserve large memory size.  One can use
> > crashkernel=xM,high to reserve it at high region (>4G) but it is more
> > convinient to improve crashkernel=X to: 
> > 
> >  - First try to reserve X below 896M (for being compatible with old
> >    kexec-tools).
> >  - If fails, try to reserve X below 4G (swiotlb need to stay below 4G).
> >  - If fails, try to reserve X from MAXMEM top down.
> > 
> > It's more transparent and user-friendly.
> > 
> > If crashkernel is large and the reserved is beyond 896M, old kexec-tools
> > is not compatible with new kernel because old kexec-tools can not load
> > kernel at high memory region, there was an old discussion below:
> > https://lkml.org/lkml/2013/10/15/601
> > 
> > But actually the behavior is consistent during my test. Suppose
> > old kernel fail to reserve memory at low areas, kdump does not
> > work because no meory reserved. With this patch, suppose new kernel
> > successfully reserved memory at high areas, old kexec-tools still fail
> > to load kdump kernel (tested 2.0.2), so it is acceptable, no need to
> > worry about the compatibility.
> > 
> > Here is the test result (kexec-tools 2.0.2, no high memory load
> > support):
> > Crashkernel over 4G:
> > # cat /proc/iomem|grep Crash
> >   be000000-cdffffff : Crash kernel
> >   213000000-21effffff : Crash kernel
> > # ./kexec  -p /boot/vmlinuz-`uname -r`
> > Memory for crashkernel is not reserved
> > Please reserve memory by passing "crashkernel=X at Y" parameter to the kernel
> > Then try loading kdump kernel
> > 
> > crashkernel: 896M-4G:
> > # cat /proc/iomem|grep Crash
> >   96000000-cdefffff : Crash kernel
> > # ./kexec -p /boot/vmlinuz-4.14.0-rc4+
> > ELF core (kcore) parse failed
> > Cannot load /boot/vmlinuz-4.14.0-rc4+
> > 
> > Signed-off-by: Dave Young <dyoung at redhat.com>
> > ---
> >  arch/x86/kernel/setup.c |   16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> > 
> > --- linux-x86.orig/arch/x86/kernel/setup.c
> > +++ linux-x86/arch/x86/kernel/setup.c
> > @@ -568,6 +568,22 @@ static void __init reserve_crashkernel(v
> >  						    high ? CRASH_ADDR_HIGH_MAX
> >  							 : CRASH_ADDR_LOW_MAX,
> >  						    crash_size, CRASH_ALIGN);
> > +#ifdef CONFIG_X86_64
> > +		/*
> > +		 * crashkernel=X reserve below 896M fails? Try below 4G
> > +		 */
> > +		if (!high && !crash_base)
> > +			crash_base = memblock_find_in_range(CRASH_ALIGN,
> > +						(1ULL << 32),
> > +						crash_size, CRASH_ALIGN);
> > +		/*
> > +		 * crashkernel=X reserve below 4G fails? Try MAXMEM
> > +		 */
> > +		if (!high && !crash_base)
> > +			crash_base = memblock_find_in_range(CRASH_ALIGN,
> > +						CRASH_ADDR_HIGH_MAX,
> > +						crash_size, CRASH_ALIGN);
> 
> For kdump, most of systems are x86 64. If both Yinghai and Vivek have no
> objection to search an available region of crash_size above 896M
> naturely, why don't we search it with function
> __memblock_find_range_bottom_up(). It can search from below 896M to
> above 4G, almost the same as the change you have made currently. Mainly
> the code will be much simpler.
> 
> The several times of searching looks not good and a little confusing.
> 
> What do you think?

Bao, thanks for the comment, it might be a good idea, will explore this
way see if there are risks to go with your suggestion.

> 
> Thanks
> Baoquan
> 
> > +#endif
> >  		if (!crash_base) {
> >  			pr_info("crashkernel reservation failed - No suitable area found.\n");
> >  			return;
> > 
> > 


From bhsharma at redhat.com  Thu Nov 16 13:29:59 2017
From: bhsharma at redhat.com (Bhupesh Sharma)
Date: Fri, 17 Nov 2017 02:59:59 +0530
Subject: [makedumpfile PATCH 1/2] Fix compilation warnings on ppc64/ppc64le
 platforms
Message-ID: <1510867800-6492-1-git-send-email-bhsharma@redhat.com>

I ran into the following compilation warnings while compiling
makedumpfile on ppc64/ppc64le platforms:

-D_LARGEFILE64_SOURCE -DVERSION='"1.6.2"' -DRELEASE_DATE='"27 Jul 2017"'
-D__powerpc64le__  -DUSELZO -DUSESNAPPY  print_info.o dwarf_info.o
elf_info.o erase_info.o sadump_info.o cache.o arch/arm.o arch/arm64.o
arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o arch/s390x.o
arch/ppc.o arch/sparc64.o -rdynamic -o makedumpfile makedumpfile.c
-lpthread -lsnappy -llzo2 -ldw -lbz2 -lebl -ldl -lelf -lz

makedumpfile.c: In function ?initial_xen?:
makedumpfile.c:9442:16: warning: unused variable ?size? [-Wunused-variable]
  unsigned long size;
                  ^
makedumpfile.c:9441:8: warning: unused variable ?offset? [-Wunused-variable]
  off_t offset;
            ^
makedumpfile.c:9440:6: warning: unused variable ?xen_info_required? [-Wunused-variable]
  int xen_info_required = TRUE;
            ^

This is caused because while we don't support Xen on powerpc,
we still have the above variables declared outside the
'#if defined(__powerpc64__) || defined(__powerpc32__)'
check.

This patch fixes the same by ensuring that these variables are only
declared for archs != powerpc.

Signed-off-by: Bhupesh Sharma <bhsharma at redhat.com>
---
 makedumpfile.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/makedumpfile.c b/makedumpfile.c
index 6d5fc8b95415..7ce0c6d648aa 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -9437,15 +9437,15 @@ exclude_xen_user_domain(void)
 int
 initial_xen(void)
 {
-	int xen_info_required = TRUE;
-	off_t offset;
-	unsigned long size;
-
 #if defined(__powerpc64__) || defined(__powerpc32__)
 	MSG("\n");
 	MSG("Xen is not supported on powerpc.\n");
 	return FALSE;
 #else
+	int xen_info_required = TRUE;
+	off_t offset;
+	unsigned long size;
+
 #ifndef __x86_64__
 	if (DL_EXCLUDE_ZERO < info->max_dump_level) {
 		MSG("Dump_level is invalid. It should be 0 or 1.\n");
-- 
2.7.4



From bhsharma at redhat.com  Thu Nov 16 13:30:00 2017
From: bhsharma at redhat.com (Bhupesh Sharma)
Date: Fri, 17 Nov 2017 03:00:00 +0530
Subject: [makedumpfile PATCH 2/2] Fix 'kernel_version' variable being
 uninitialized & introduce minor reorganization
In-Reply-To: <1510867800-6492-1-git-send-email-bhsharma@redhat.com>
References: <1510867800-6492-1-git-send-email-bhsharma@redhat.com>
Message-ID: <1510867800-6492-2-git-send-email-bhsharma@redhat.com>

On executing `makedumpfile --mem-usage /proc/kcore`, it
fails currently with the following error message on newer Linux kernels
like 4.13.0 or 4.14.0:

mem-usage not supported for this kernel.
You can try with -f if your kernel's kcore has valid p_paddr
makedumpfile Failed.

This happens because 'info->kernel_version' is uninitialized in function
main(). So when we perform the following check, it fails even though the
kernel version is greater than 4.11.0:

if (info->kernel_version < KERNEL_VERSION(4, 11, 0) &&
				!info->flag_force) {

Fix this by reorganizing the code to:
- Add an API to populate the kernel version.
- Call this API rather than replicating the open code across other APIs
  across 'makedumpfile.c'

After this patch, '--mem-usage' can be used properly with makedumpfile.
Here are the logs I observe on a Fedora 26 ppc64le system:

The kernel version is not supported.
The makedumpfile operation may be incomplete.

TYPE		PAGES			EXCLUDABLE	DESCRIPTION
----------------------------------------------------------------------
ZERO		99              	yes		Pages filled
with zero
NON_PRI_CACHE	7817            	yes		Cache pages
without private flag
PRI_CACHE	63603           	yes		Cache pages with
private flag
USER		4105            	yes		User process
pages
FREE		165446          	yes		Free pages
KERN_DATA	6738            	no		Dumpable kernel
data

page size:		65536
Total pages on system:	247808
Total size on system:	16240345088      Byte

Signed-off-by: Bhupesh Sharma <bhsharma at redhat.com>
---
 makedumpfile.c | 31 ++++++++++++++++++++-----------
 1 file changed, 20 insertions(+), 11 deletions(-)

diff --git a/makedumpfile.c b/makedumpfile.c
index 7ce0c6d648aa..4bde542b4f0c 100644
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -1089,6 +1089,21 @@ fallback_to_current_page_size(void)
 	return TRUE;
 }
 
+static int populate_kernel_version(void)
+{
+	struct utsname utsname;
+
+	if (uname(&utsname)) {
+		ERRMSG("Cannot get name and information about current kernel : %s\n",
+		       strerror(errno));
+		return FALSE;
+	}
+
+	info->kernel_version = get_kernel_version(utsname.release);
+
+	return TRUE;
+}
+
 int
 check_release(void)
 {
@@ -1120,11 +1135,8 @@ check_release(void)
 		}
 	}
 
-	info->kernel_version = get_kernel_version(info->system_utsname.release);
-	if (info->kernel_version == FALSE) {
-		ERRMSG("Can't get the kernel version.\n");
+	if (!populate_kernel_version())
 		return FALSE;
-	}
 
 	return TRUE;
 }
@@ -10973,20 +10985,14 @@ int is_crashkernel_mem_reserved(void)
 
 static int get_page_offset(void)
 {
-	struct utsname utsname;
-	if (uname(&utsname)) {
-		ERRMSG("Cannot get name and information about current kernel : %s",
-		       strerror(errno));
+	if (!populate_kernel_version())
 		return FALSE;
-	}
 
-	info->kernel_version = get_kernel_version(utsname.release);
 	get_versiondep_info();
 
 	return TRUE;
 }
 
-
 /* Returns the physical address of start of crash notes buffer for a kernel. */
 static int get_sys_kernel_vmcoreinfo(uint64_t *addr, uint64_t *len)
 {
@@ -11363,6 +11369,9 @@ main(int argc, char *argv[])
 			MSG("Try `makedumpfile --help' for more information.\n");
 			goto out;
 		}
+		if (!populate_kernel_version())
+			goto out;
+
 		if (info->kernel_version < KERNEL_VERSION(4, 11, 0) &&
 				!info->flag_force) {
 			MSG("mem-usage not supported for this kernel.\n");
-- 
2.7.4



From dyoung at redhat.com  Fri Nov 17 20:47:11 2017
From: dyoung at redhat.com (Dave Young)
Date: Sat, 18 Nov 2017 12:47:11 +0800
Subject: [PATCH] certs: always use secondary keyring first if possible
Message-ID: <20171118044711.GA7352@dhcp-128-65.nay.redhat.com>

Commit d3bfe84129f6 introduced secondary_trusted_keys keyring, current
users of verify_pkcs7_signature are below:
net/wireless/reg.c : uses its own trusted_keys
kernel/module_signing.c : pass NULL trusted_keys 
crypto/asymmetric_keys/verify_pefile.c : pass NULL trusted_keys

For both module and pefile verification, there is no reason to use builtin
keys only. Actually in Fedora kernel module signing code passes 1UL, but
kexec code does not pass 1UL for pefile verification thus we have below bug
https://bugzilla.redhat.com/show_bug.cgi?id=1470995

Drop the hard code 1UL checking so that pefile verification can use
secondary keyring as well.

Signed-off-by: Dave Young <dyoung at redhat.com>
---
 certs/system_keyring.c |    2 --
 1 file changed, 2 deletions(-)

--- linux-x86.orig/certs/system_keyring.c
+++ linux-x86/certs/system_keyring.c
@@ -229,8 +229,6 @@ int verify_pkcs7_signature(const void *d
 		goto error;
 
 	if (!trusted_keys) {
-		trusted_keys = builtin_trusted_keys;
-	} else if (trusted_keys == (void *)1UL) {
 #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
 		trusted_keys = secondary_trusted_keys;
 #else


From ats-kumagai at wm.jp.nec.com  Sun Nov 19 16:19:34 2017
From: ats-kumagai at wm.jp.nec.com (Atsushi Kumagai)
Date: Mon, 20 Nov 2017 00:19:34 +0000
Subject: [makedumpfile PATCH 1/2] Fix compilation warnings on
 ppc64/ppc64le platforms
In-Reply-To: <1510867800-6492-1-git-send-email-bhsharma@redhat.com>
References: <1510867800-6492-1-git-send-email-bhsharma@redhat.com>
Message-ID: <0910DD04CBD6DE4193FCF86B9C00BE9701F263B0@BPXM01GP.gisp.nec.co.jp>

Hello Bhupesh,

Thanks for your work, I'll merge these patches into v1.6.3.

Regards
Atsushi Kumagai

>I ran into the following compilation warnings while compiling
>makedumpfile on ppc64/ppc64le platforms:
>
>-D_LARGEFILE64_SOURCE -DVERSION='"1.6.2"' -DRELEASE_DATE='"27 Jul 2017"'
>-D__powerpc64le__  -DUSELZO -DUSESNAPPY  print_info.o dwarf_info.o
>elf_info.o erase_info.o sadump_info.o cache.o arch/arm.o arch/arm64.o
>arch/x86.o arch/x86_64.o arch/ia64.o arch/ppc64.o arch/s390x.o
>arch/ppc.o arch/sparc64.o -rdynamic -o makedumpfile makedumpfile.c
>-lpthread -lsnappy -llzo2 -ldw -lbz2 -lebl -ldl -lelf -lz
>
>makedumpfile.c: In function ?initial_xen?:
>makedumpfile.c:9442:16: warning: unused variable ?size? [-Wunused-variable]
>  unsigned long size;
>                  ^
>makedumpfile.c:9441:8: warning: unused variable ?offset? [-Wunused-variable]
>  off_t offset;
>            ^
>makedumpfile.c:9440:6: warning: unused variable ?xen_info_required? [-Wunused-variable]
>  int xen_info_required = TRUE;
>            ^
>
>This is caused because while we don't support Xen on powerpc,
>we still have the above variables declared outside the
>'#if defined(__powerpc64__) || defined(__powerpc32__)'
>check.
>
>This patch fixes the same by ensuring that these variables are only
>declared for archs != powerpc.
>
>Signed-off-by: Bhupesh Sharma <bhsharma at redhat.com>
>---
> makedumpfile.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/makedumpfile.c b/makedumpfile.c
>index 6d5fc8b95415..7ce0c6d648aa 100644
>--- a/makedumpfile.c
>+++ b/makedumpfile.c
>@@ -9437,15 +9437,15 @@ exclude_xen_user_domain(void)
> int
> initial_xen(void)
> {
>-	int xen_info_required = TRUE;
>-	off_t offset;
>-	unsigned long size;
>-
> #if defined(__powerpc64__) || defined(__powerpc32__)
> 	MSG("\n");
> 	MSG("Xen is not supported on powerpc.\n");
> 	return FALSE;
> #else
>+	int xen_info_required = TRUE;
>+	off_t offset;
>+	unsigned long size;
>+
> #ifndef __x86_64__
> 	if (DL_EXCLUDE_ZERO < info->max_dump_level) {
> 		MSG("Dump_level is invalid. It should be 0 or 1.\n");
>--
>2.7.4

From horms at verge.net.au  Mon Nov 20 01:36:17 2017
From: horms at verge.net.au (Simon Horman)
Date: Mon, 20 Nov 2017 10:36:17 +0100
Subject: [ANNOUNCE] kexec-tools 2.0.16
Message-ID: <20171120093617.6btks4ijakzi4yil@verge.net.au>

Hi all,

I am happy to announce the release of kexec-tools 2.0.16.

This is a feature release coinciding with the release of v4.14 of the Linux
Kernel.

This release can be downloaded from kernel.org:

	http://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.16.tar.xz
	http://kernel.org/pub/linux/utils/kernel/kexec/

It is also tagged it in git:

	git://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git

Thanks to everyone who has contributed to kexec.


From jbohac at suse.cz  Tue Nov 28 13:58:33 2017
From: jbohac at suse.cz (Jiri Bohac)
Date: Tue, 28 Nov 2017 22:58:33 +0100
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171112080426.GB6429@x1>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
 <20171106024143.GA3669@x1>
 <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
 <20171106092729.GB3669@x1>
 <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz>
 <20171107113956.GC3669@x1>
 <20171107134212.tmjdt7rdailtbosa@dwarf.suse.cz>
 <20171107153428.ex27nwkvelhm2nm7@dwarf.suse.cz>
 <20171112080426.GB6429@x1>
Message-ID: <20171128215833.hhcjvn5qjfc3bdrk@dwarf.suse.cz>

Hi Baoquan,

On Sun, Nov 12, 2017 at 04:04:26PM +0800, Baoquan He wrote:
> Solution:
> 1) Remove the code which support GART IOMMU when it's not enabled in
> BIOS. This has been done in the new generation of hardware IOMMU like
> intel vt-d IOMMU and amd-Vi IOMMU. We should not make GART IOMMU be
> exceptional.

Wouldn't this break old machines with actual AGP and
misconfigured/bugg BIOSes? Wasn't that the reason why we have the
workaround of mapping the hole over real memory?
 
> 2) Remove those pages from mm subsystem since they are not seen any more
> though they have been added into mm subsystem, because CPU can't see
> them.

not exactly sure I understand this... they are reserved by the
memblock allocater, thus preventing any further use by any mm
code.

> 3) Remove the apreture region from /proc/iomem so that pages in that
> region can't be seen by kdump kernel. This is easier, but just a work
> around.

I like this idea, but won't this cause pci_claim_resource() fail
after the call to pci_find_parent_resource() ? See my previous
mail.


Bad thing is, we don't want to break random old AGP hardware, but
at the same time, it's now too rare to properly test this.

So wouldn't it be better to fix the problem at least for the
kexec_file case using my original patch?

A possible hack for the old kexec syscall might be to
make /proc/iomem list the "GART" region without it being present in
the iomem resource database. kexec-tools has working code to deal with
the GART region, but the kernel no longer includes it in
/proc/iomem.

Or maybe a cleaner solution than special-casing the "GART" region
into /proc/iomem would be to introduce a new type of iomem
resource that would be visible in /proc/iomem but would allow
other resources to be requested even when overlapping the region of this
special resource? This way, we could insert the "GART" resource
when allocating the hole but later, when an actual AGP driver
requests the range during PCI enumeration, the "GART" resource
would be overwrtiten by the actual PCI resource.

-- 
Jiri Bohac <jbohac at suse.cz>
SUSE Labs, Prague, Czechia



From dyoung at redhat.com  Tue Nov 28 18:15:04 2017
From: dyoung at redhat.com (Dave Young)
Date: Wed, 29 Nov 2017 10:15:04 +0800
Subject: [PATCH] certs: always use secondary keyring first if possible
In-Reply-To: <20171118044711.GA7352@dhcp-128-65.nay.redhat.com>
References: <20171118044711.GA7352@dhcp-128-65.nay.redhat.com>
Message-ID: <20171129021504.GA4080@dhcp-128-65.nay.redhat.com>

On 11/18/17 at 12:47pm, Dave Young wrote:
> Commit d3bfe84129f6 introduced secondary_trusted_keys keyring, current
> users of verify_pkcs7_signature are below:
> net/wireless/reg.c : uses its own trusted_keys
> kernel/module_signing.c : pass NULL trusted_keys 
> crypto/asymmetric_keys/verify_pefile.c : pass NULL trusted_keys
> 
> For both module and pefile verification, there is no reason to use builtin
> keys only. Actually in Fedora kernel module signing code passes 1UL, but
> kexec code does not pass 1UL for pefile verification thus we have below bug
> https://bugzilla.redhat.com/show_bug.cgi?id=1470995
> 
> Drop the hard code 1UL checking so that pefile verification can use
> secondary keyring as well.
> 
> Signed-off-by: Dave Young <dyoung at redhat.com>
> ---
>  certs/system_keyring.c |    2 --
>  1 file changed, 2 deletions(-)
> 
> --- linux-x86.orig/certs/system_keyring.c
> +++ linux-x86/certs/system_keyring.c
> @@ -229,8 +229,6 @@ int verify_pkcs7_signature(const void *d
>  		goto error;
>  
>  	if (!trusted_keys) {
> -		trusted_keys = builtin_trusted_keys;
> -	} else if (trusted_keys == (void *)1UL) {
>  #ifdef CONFIG_SECONDARY_TRUSTED_KEYRING
>  		trusted_keys = secondary_trusted_keys;
>  #else

Ping, can anyone review this?

Thanks
Dave


From bhe at redhat.com  Tue Nov 28 18:43:07 2017
From: bhe at redhat.com (Baoquan He)
Date: Wed, 29 Nov 2017 10:43:07 +0800
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171128215833.hhcjvn5qjfc3bdrk@dwarf.suse.cz>
References: <20171103172822.4ty6yjhewroe4z4j@dwarf.suse.cz>
 <20171106024143.GA3669@x1>
 <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
 <20171106092729.GB3669@x1>
 <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz>
 <20171107113956.GC3669@x1>
 <20171107134212.tmjdt7rdailtbosa@dwarf.suse.cz>
 <20171107153428.ex27nwkvelhm2nm7@dwarf.suse.cz>
 <20171112080426.GB6429@x1>
 <20171128215833.hhcjvn5qjfc3bdrk@dwarf.suse.cz>
Message-ID: <20171129024307.GE15074@x1>

On 11/28/17 at 10:58pm, Jiri Bohac wrote:
> Hi Baoquan,
> 
> On Sun, Nov 12, 2017 at 04:04:26PM +0800, Baoquan He wrote:
> > Solution:
> > 1) Remove the code which support GART IOMMU when it's not enabled in
> > BIOS. This has been done in the new generation of hardware IOMMU like
> > intel vt-d IOMMU and amd-Vi IOMMU. We should not make GART IOMMU be
> > exceptional.
> 
> Wouldn't this break old machines with actual AGP and
> misconfigured/bugg BIOSes? Wasn't that the reason why we have the
> workaround of mapping the hole over real memory?

Hmm, a quick question, does it work when GART support is enabled in
bios? In intel vt-d and amd-vi iommu, if user doesn't enable it in bios,
the functionality will be disabled in kernel, why would we not do that
for GART IOMMU? and why is GART so special?

GART could be the only feature in kernel I saw which bios option is not
enabled but still get supported. Doesn't it look very weird?

>  
> > 2) Remove those pages from mm subsystem since they are not seen any more
> > though they have been added into mm subsystem, because CPU can't see
> > them.
> 
> not exactly sure I understand this... they are reserved by the
> memblock allocater, thus preventing any further use by any mm
> code.

Many kernel pages are reverved from memblock, why can you still read
their content?

> 
> > 3) Remove the apreture region from /proc/iomem so that pages in that
> > region can't be seen by kdump kernel. This is easier, but just a work
> > around.
> 
> I like this idea, but won't this cause pci_claim_resource() fail
> after the call to pci_find_parent_resource() ? See my previous
> mail.

Not very sure, now have not time to investigate why it cause failure.

I tried to find a system with GART in our lab, but failed. Those
machines are too old, at least in redhat I never heard complain about
it. If have a easy fix, worth to have a try. otherwise, may just better
to leave it as is. That's why I suggested the 1st choice, and also the
work around code is too quirky if GART bios is not enabled.

> 
> 
> Bad thing is, we don't want to break random old AGP hardware, but
> at the same time, it's now too rare to properly test this.
> 
> So wouldn't it be better to fix the problem at least for the
> kexec_file case using my original patch?
> 
> A possible hack for the old kexec syscall might be to
> make /proc/iomem list the "GART" region without it being present in
> the iomem resource database. kexec-tools has working code to deal with
> the GART region, but the kernel no longer includes it in
> /proc/iomem.
> 
> Or maybe a cleaner solution than special-casing the "GART" region
> into /proc/iomem would be to introduce a new type of iomem
> resource that would be visible in /proc/iomem but would allow
> other resources to be requested even when overlapping the region of this
> special resource? This way, we could insert the "GART" resource
> when allocating the hole but later, when an actual AGP driver
> requests the range during PCI enumeration, the "GART" resource
> would be overwrtiten by the actual PCI resource.
> 
> -- 
> Jiri Bohac <jbohac at suse.cz>
> SUSE Labs, Prague, Czechia
> 
> 
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


From Anil.Gurumurthy at cavium.com  Tue Nov 28 21:29:25 2017
From: Anil.Gurumurthy at cavium.com (Gurumurthy, Anil)
Date: Wed, 29 Nov 2017 05:29:25 +0000
Subject: kdump issues with 4.11 kernel
Message-ID: <BY2PR0701MB202342812CFB9669B01930D98E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>

Hello,
? I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?

[root at localhost ~]# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`kdump.img
ELF core (kcore) parse failed
Cannot load /boot/vmlinuz-4.11.12+

[root at localhost ~]# ls -l /boot/vmlinuz-4.11.12+
-rw-r--r--. 1 root root 6404384 Nov 23 12:14 /boot/vmlinuz-4.11.12+
[root at localhost ~]# cat /sys/kernel/kexec_crash_size
134217728
[root at localhost ~]# cat /proc/iomem | grep -i crash
? 30000000-37ffffff : Crash kernel

[root at localhost ~]# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`kdump.img -d
kernel: 0x7fa8ba785010 kernel_size: 0x61b920
MEMORY RANGES
0000000000000100-000000000006bfff (0)
000000000006c000-000000000006cfff (3)
000000000006d000-000000000009efff (0)
000000000009f000-000000000009ffff (3)
0000000000100000-000000004578d017 (0)
000000004578d018-00000000457aee57 (0)
00000000457aee58-00000000457af017 (0)
00000000457af018-00000000457d0e57 (0)
00000000457d0e58-00000000457d1017 (0)
00000000457d1018-00000000457f2e57 (0)
00000000457f2e58-00000000457f3017 (0)
00000000457f3018-0000000045814e57 (0)
0000000045814e58-0000000045815017 (0)
0000000045815018-000000004584ec57 (0)
000000004584ec58-000000004584f017 (0)
000000004584f018-0000000045888c57 (0)
0000000045888c58-000000005d13c017 (0)
000000005d13c018-000000005d14b057 (0)
000000005d14b058-000000005d14c017 (0)
000000005d14c018-000000005d15f657 (0)
000000005d15f658-000000005d184fff (0)
000000005d185000-000000005d185fff (2)
000000005d186000-000000005fb76fff (0)
000000005fb77000-000000005fb7bfff (1)
000000005fb7c000-000000005ffe0fff (0)
000000005ffe1000-000000005ffe1fff (2)
000000005ffe2000-000000005fff9fff (0)
000000005fffa000-0000000060001fff (2)
0000000060002000-0000000060009fff (0)
000000006000a000-000000006000afff (2)
000000006000b000-000000006000bfff (0)
000000006000c000-0000000060011fff (2)
0000000060012000-00000000600ddfff (0)
00000000600de000-00000000600e0fff (2)
00000000600e1000-00000000600e2fff (1)
00000000600e3000-00000000600e4fff (2)
00000000600e5000-00000000606e2fff (0)
00000000606e3000-00000000606e3fff (2)
00000000606e4000-0000000060e52fff (0)
0000000060e53000-0000000060e53fff (2)
0000000060e54000-00000000735d9fff (0)
00000000735da000-00000000735e6fff (1)
00000000735e7000-0000000074413fff (0)
0000000074414000-000000007e892fff (1)
000000007e893000-000000007eb9efff (3)
000000007eb9f000-000000007ec01fff (0)
0000000080000000-000000008fffffff (1)
00000000fed1c000-00000000fed1ffff (1)
00000000ff800000-00000000ffffffff (1)
0000000100000000-0000000a7fffffff (0)
0000000000000000-0000000000000fff : reserved
0000000000001000-000000000006bfff : System RAM
000000000006c000-000000000006cfff : ACPI Non-volatile Storage
000000000006d000-000000000009efff : System RAM
000000000009f000-000000000009ffff : ACPI Non-volatile Storage
00000000000a0000-00000000000bffff : PCI Bus 0000:00
00000000000c0000-00000000000c7fff : Video ROM
00000000000f0000-00000000000fffff : System ROM
0000000000100000-000000004578d017 : System RAM
0000000030000000-0000000037ffffff : Crash kernel
000000004578d018-00000000457aee57 : System RAM
00000000457aee58-00000000457af017 : System RAM
00000000457af018-00000000457d0e57 : System RAM
00000000457d0e58-00000000457d1017 : System RAM
00000000457d1018-00000000457f2e57 : System RAM
00000000457f2e58-00000000457f3017 : System RAM
00000000457f3018-0000000045814e57 : System RAM
0000000045814e58-0000000045815017 : System RAM
0000000045815018-000000004584ec57 : System RAM
000000004584ec58-000000004584f017 : System RAM
000000004584f018-0000000045888c57 : System RAM
0000000045888c58-000000005d13c017 : System RAM
000000005d13c018-000000005d14b057 : System RAM
000000005d14b058-000000005d14c017 : System RAM
000000005d14c018-000000005d15f657 : System RAM
000000005d15f658-000000005d184fff : System RAM
000000005d185000-000000005d185fff : ACPI Tables
000000005d186000-000000005fb76fff : System RAM
000000005fb77000-000000005fb7bfff : reserved
000000005fb7c000-000000005ffe0fff : System RAM
000000005ffe1000-000000005ffe1fff : ACPI Tables
000000005ffe2000-000000005fff9fff : System RAM
000000005fffa000-0000000060001fff : ACPI Tables
0000000060002000-0000000060009fff : System RAM
000000006000a000-000000006000afff : ACPI Tables
000000006000b000-000000006000bfff : System RAM
000000006000c000-0000000060011fff : ACPI Tables
0000000060012000-00000000600ddfff : System RAM
00000000600de000-00000000600e0fff : ACPI Tables
00000000600e1000-00000000600e2fff : reserved
00000000600e3000-00000000600e4fff : ACPI Tables
00000000600e5000-00000000606e2fff : System RAM
00000000606e3000-00000000606e3fff : ACPI Tables
00000000606e4000-0000000060e52fff : System RAM
0000000060e53000-0000000060e53fff : ACPI Tables
0000000060e54000-00000000735d9fff : System RAM
00000000735da000-00000000735e6fff : reserved
00000000735e7000-0000000074413fff : System RAM
0000000074414000-000000007e892fff : reserved
000000007e893000-000000007eb9efff : ACPI Non-volatile Storage
000000007eb9f000-000000007ec01fff : System RAM
000000007ec02000-000000007fffffff : RAM buffer
0000000080000000-000000008fffffff : PCI MMCONFIG 0000 [bus 00-ff]
0000000080000000-000000008fffffff : reserved
0000000090000000-00000000c3ff7fff : PCI Bus 0000:80
0000000090000000-0000000090003fff : 0000:80:04.0
0000000090000000-0000000090003fff : ioatdma
0000000090004000-0000000090007fff : 0000:80:04.1
0000000090004000-0000000090007fff : ioatdma
0000000090008000-000000009000bfff : 0000:80:04.2
0000000090008000-000000009000bfff : ioatdma
000000009000c000-000000009000ffff : 0000:80:04.3
000000009000c000-000000009000ffff : ioatdma
0000000090010000-0000000090013fff : 0000:80:04.4
0000000090010000-0000000090013fff : ioatdma
0000000090014000-0000000090017fff : 0000:80:04.5
0000000090014000-0000000090017fff : ioatdma
0000000090018000-000000009001bfff : 0000:80:04.6
0000000090018000-000000009001bfff : ioatdma
000000009001c000-000000009001ffff : 0000:80:04.7
000000009001c000-000000009001ffff : ioatdma
00000000c3ff8000-00000000c3ff8fff : dmar0
00000000c4000000-00000000fbff7fff : PCI Bus 0000:00
00000000c4000000-00000000c40fffff : PCI Bus 0000:20
00000000c4000000-00000000c403ffff : 0000:20:00.0
00000000c4040000-00000000c407ffff : 0000:20:00.1
00000000c42fd000-00000000c42fd3ff : 0000:00:1a.0
00000000c42fd000-00000000c42fd3ff : ehci_hcd
00000000c42fe000-00000000c42fe3ff : 0000:00:1d.0
00000000c42fe000-00000000c42fe3ff : ehci_hcd
00000000c42ff000-00000000c42ff7ff : 0000:00:1f.2
00000000c42ff000-00000000c42ff7ff : ahci
00000000c4300000-00000000c43fffff : PCI Bus 0000:16
00000000c4300000-00000000c431ffff : 0000:16:00.0
00000000c43bc000-00000000c43bffff : 0000:16:00.0
00000000c43bc000-00000000c43bffff : megasas: LSI
00000000c43c0000-00000000c43fffff : 0000:16:00.0
00000000c4400000-00000000c45fffff : PCI Bus 0000:06
00000000c4470000-00000000c4473fff : 0000:06:00.0
00000000c4470000-00000000c4473fff : igb
00000000c4474000-00000000c4493fff : 0000:06:00.0
00000000c4494000-00000000c44b3fff : 0000:06:00.0
00000000c44b4000-00000000c44b7fff : 0000:06:00.1
00000000c44b4000-00000000c44b7fff : igb
00000000c44b8000-00000000c44d7fff : 0000:06:00.1
00000000c44d8000-00000000c44f7fff : 0000:06:00.1
00000000c44f8000-00000000c44fbfff : 0000:06:00.2
00000000c44f8000-00000000c44fbfff : igb
00000000c44fc000-00000000c451bfff : 0000:06:00.2
00000000c451c000-00000000c453bfff : 0000:06:00.2
00000000c453c000-00000000c453ffff : 0000:06:00.3
00000000c453c000-00000000c453ffff : igb
00000000c4540000-00000000c455ffff : 0000:06:00.3
00000000c4560000-00000000c457ffff : 0000:06:00.3
00000000c4580000-00000000c459ffff : 0000:06:00.0
00000000c4580000-00000000c459ffff : igb
00000000c45a0000-00000000c45bffff : 0000:06:00.1
00000000c45a0000-00000000c45bffff : igb
00000000c45c0000-00000000c45dffff : 0000:06:00.2
00000000c45c0000-00000000c45dffff : igb
00000000c45e0000-00000000c45fffff : 0000:06:00.3
00000000c45e0000-00000000c45fffff : igb
00000000c4600000-00000000c4ffffff : PCI Bus 0000:01
00000000c4600000-00000000c4ffffff : PCI Bus 0000:02
00000000c4600000-00000000c46fffff : PCI Bus 0000:05
00000000c4700000-00000000c4ffffff : PCI Bus 0000:03
00000000c4700000-00000000c4ffffff : PCI Bus 0000:04
00000000c47fc000-00000000c47fffff : 0000:04:00.0
00000000c47fc000-00000000c47fffff : mgadrmfb_mmio
00000000c4800000-00000000c4ffffff : 0000:04:00.0
00000000c5000000-00000000c5ffffff : PCI Bus 0000:01
00000000c5000000-00000000c5ffffff : PCI Bus 0000:02
00000000c5000000-00000000c5ffffff : PCI Bus 0000:03
00000000c5000000-00000000c5ffffff : PCI Bus 0000:04
00000000c5000000-00000000c5ffffff : 0000:04:00.0
00000000c5000000-00000000c5ffffff : mgadrmfb_vram
00000000c60e0000-00000000c60e3fff : 0000:00:04.0
00000000c60e0000-00000000c60e3fff : ioatdma
00000000c60e4000-00000000c60e7fff : 0000:00:04.1
00000000c60e4000-00000000c60e7fff : ioatdma
00000000c60e8000-00000000c60ebfff : 0000:00:04.2
00000000c60e8000-00000000c60ebfff : ioatdma
00000000c60ec000-00000000c60effff : 0000:00:04.3
00000000c60ec000-00000000c60effff : ioatdma
00000000c60f0000-00000000c60f3fff : 0000:00:04.4
00000000c60f0000-00000000c60f3fff : ioatdma
00000000c60f4000-00000000c60f7fff : 0000:00:04.5
00000000c60f4000-00000000c60f7fff : ioatdma
00000000c60f8000-00000000c60fbfff : 0000:00:04.6
00000000c60f8000-00000000c60fbfff : ioatdma
00000000c60fc000-00000000c60fffff : 0000:00:04.7
00000000c60fc000-00000000c60fffff : ioatdma
00000000c6100000-00000000c63fffff : PCI Bus 0000:20
00000000c61fa000-00000000c61fafff : 0000:20:00.0
00000000c61fa000-00000000c61fafff : qla2xxx
00000000c61fb000-00000000c61fbfff : 0000:20:00.1
00000000c61fb000-00000000c61fbfff : qla2xxx
00000000c61fc000-00000000c61fdfff : 0000:20:00.0
00000000c61fc000-00000000c61fdfff : qla2xxx
00000000c61fe000-00000000c61fffff : 0000:20:00.1
00000000c61fe000-00000000c61fffff : qla2xxx
00000000c6200000-00000000c62fffff : 0000:20:00.0
00000000c6200000-00000000c62fffff : qla2xxx
00000000c6300000-00000000c63fffff : 0000:20:00.1
00000000c6300000-00000000c63fffff : qla2xxx
00000000fbff8000-00000000fbff8fff : dmar1
00000000fec00000-00000000fecfffff : PNP0003:00
00000000fec00000-00000000fec003ff : IOAPIC 0
00000000fec01000-00000000fec013ff : IOAPIC 1
00000000fec40000-00000000fec403ff : IOAPIC 2
00000000fed00000-00000000fed003ff : HPET 0
00000000fed00000-00000000fed003ff : PNP0103:00
00000000fed1b000-00000000fed1bfff : pnp 00:01
00000000fed1c000-00000000fed1ffff : reserved
00000000fed1f410-00000000fed1f414 : iTCO_wdt.0.auto
00000000fed40000-00000000fedfffff : PCI Bus 0000:00
00000000fed40000-00000000fed44fff : TPM
00000000fee00000-00000000feefffff : pnp 00:01
00000000fee00000-00000000fee00fff : Local APIC
00000000ff800000-00000000ffffffff : reserved
0000000100000000-0000000a7fffffff : System RAM
00000007e7600000-00000007e7d62a60 : Kernel code
00000007e7d62a61-00000007e838c9ff : Kernel data
00000007e85c6000-00000007e88dcfff : Kernel bss
0000038000000000-00000387ffffffff : PCI Bus 0000:00
0000038800000000-0000038fffffffff : PCI Bus 0000:80
get_backup_area: 0000000000001000-000000000006bfff : System RAM
CRASH MEMORY RANGES
0000000000000000-0000000000000fff (1)
0000000000001000-000000000006bfff (0)
000000000006c000-000000000006cfff (3)
000000000006d000-000000000009efff (0)
000000000009f000-000000000009ffff (3)
0000000000100000-000000002fffffff (0)
0000000038000000-000000004578d017 (0)
000000004578d018-00000000457aee57 (0)
00000000457aee58-00000000457af017 (0)
00000000457af018-00000000457d0e57 (0)
00000000457d0e58-00000000457d1017 (0)
00000000457d1018-00000000457f2e57 (0)
00000000457f2e58-00000000457f3017 (0)
00000000457f3018-0000000045814e57 (0)
0000000045814e58-0000000045815017 (0)
0000000045815018-000000004584ec57 (0)
000000004584ec58-000000004584f017 (0)
000000004584f018-0000000045888c57 (0)
0000000045888c58-000000005d13c017 (0)
000000005d13c018-000000005d14b057 (0)
000000005d14b058-000000005d14c017 (0)
000000005d14c018-000000005d15f657 (0)
000000005d15f658-000000005d184fff (0)
000000005d185000-000000005d185fff (2)
000000005d186000-000000005fb76fff (0)
000000005fb77000-000000005fb7bfff (1)
000000005fb7c000-000000005ffe0fff (0)
000000005ffe1000-000000005ffe1fff (2)
000000005ffe2000-000000005fff9fff (0)
000000005fffa000-0000000060001fff (2)
0000000060002000-0000000060009fff (0)
000000006000a000-000000006000afff (2)
000000006000b000-000000006000bfff (0)
000000006000c000-0000000060011fff (2)
0000000060012000-00000000600ddfff (0)
00000000600de000-00000000600e0fff (2)
00000000600e1000-00000000600e2fff (1)
00000000600e3000-00000000600e4fff (2)
00000000600e5000-00000000606e2fff (0)
00000000606e3000-00000000606e3fff (2)
00000000606e4000-0000000060e52fff (0)
0000000060e53000-0000000060e53fff (2)
0000000060e54000-00000000735d9fff (0)
00000000735da000-00000000735e6fff (1)
00000000735e7000-0000000074413fff (0)
0000000074414000-000000007e892fff (1)
000000007e893000-000000007eb9efff (3)
000000007eb9f000-000000007ec01fff (0)
0000000080000000-000000008fffffff (1)
00000000fed1c000-00000000fed1ffff (1)
00000000ff800000-00000000ffffffff (1)
0000000100000000-0000000a7fffffff (0)
kernel load physical addr start = 0x00000007e7600000
ELF core (kcore) parse failed
Cannot load /boot/vmlinuz-4.11.12+


From dyoung at redhat.com  Tue Nov 28 23:38:41 2017
From: dyoung at redhat.com (Dave Young)
Date: Wed, 29 Nov 2017 15:38:41 +0800
Subject: kdump issues with 4.11 kernel
In-Reply-To: <BY2PR0701MB202342812CFB9669B01930D98E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
References: <BY2PR0701MB202342812CFB9669B01930D98E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
Message-ID: <20171129073841.GA2129@dhcp-128-65.nay.redhat.com>

Hi,
On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
> Hello,
> ? I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
> 
> [root at localhost ~]# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`kdump.img
> ELF core (kcore) parse failed
> Cannot load /boot/vmlinuz-4.11.12+
> 

Can you try below kexec-tools commit:
commit ed15ba1b9977e506637ff1697821d97127b2c919
Author: Pratyush Anand <panand at redhat.com>
Date:   Wed Mar 1 11:19:42 2017 +0530

    build_mem_phdrs(): check if p_paddr is invalid

Thanks
Dave


From Anil.Gurumurthy at cavium.com  Wed Nov 29 01:14:42 2017
From: Anil.Gurumurthy at cavium.com (Gurumurthy, Anil)
Date: Wed, 29 Nov 2017 09:14:42 +0000
Subject: kdump issues with 4.11 kernel
In-Reply-To: <20171129073841.GA2129@dhcp-128-65.nay.redhat.com>
References: <BY2PR0701MB202342812CFB9669B01930D98E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <20171129073841.GA2129@dhcp-128-65.nay.redhat.com>
Message-ID: <BY2PR0701MB2023DAF450CE2EB7270E05A38E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>

Thanks. That did help getting kexec to work.
However I still do not get a crash dump - 
echo c  > /proc/sysrq-trigger does not get a crash dump.

Any thoughts?

Thanks,
Anil

-----Original Message-----
From: Dave Young [mailto:dyoung at redhat.com] 
Sent: 29 November 2017 13:09
To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
Cc: kexec at lists.infradead.org
Subject: Re: kdump issues with 4.11 kernel

Hi,
On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
> Hello,
> ? I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
> 
> [root at localhost ~]# kexec -p /boot/vmlinuz-`uname -r` 
> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse 
> failed Cannot load /boot/vmlinuz-4.11.12+
> 

Can you try below kexec-tools commit:
commit ed15ba1b9977e506637ff1697821d97127b2c919
Author: Pratyush Anand <panand at redhat.com>
Date:   Wed Mar 1 11:19:42 2017 +0530

    build_mem_phdrs(): check if p_paddr is invalid

Thanks
Dave


From bhsharma at redhat.com  Wed Nov 29 01:46:27 2017
From: bhsharma at redhat.com (Bhupesh Sharma)
Date: Wed, 29 Nov 2017 15:16:27 +0530
Subject: kdump issues with 4.11 kernel
In-Reply-To: <BY2PR0701MB2023DAF450CE2EB7270E05A38E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
References: <BY2PR0701MB202342812CFB9669B01930D98E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <20171129073841.GA2129@dhcp-128-65.nay.redhat.com>
 <BY2PR0701MB2023DAF450CE2EB7270E05A38E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
Message-ID: <CACi5LpP9+5YVVh1DtnWXCMQbFMRJ1NVYh=_nQYcpShZS0es7hg@mail.gmail.com>

Hi Anil,

On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil
<Anil.Gurumurthy at cavium.com> wrote:
> Thanks. That did help getting kexec to work.
> However I still do not get a crash dump -
> echo c  > /proc/sysrq-trigger does not get a crash dump.
>
> Any thoughts?

Cam you share the console messages you see when the crash kernel
boots? Or do you see nothing after the crash is introduced via echo c
> /proc/sysrq-trigger

Generally, depending on your test machine arch, it is useful to use
earlycon/earlyprintk to see if the crash kernel produced any useful
message until the actual console device became operational.

Can you try setting the earlycon/earlyprintk settings and share the
crash kernel logs messages after the same?

Thanks,
Bhupesh

> -----Original Message-----
> From: Dave Young [mailto:dyoung at redhat.com]
> Sent: 29 November 2017 13:09
> To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
> Cc: kexec at lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> Hi,
> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>> Hello,
>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>
>> [root at localhost ~]# kexec -p /boot/vmlinuz-`uname -r`
>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse
>> failed Cannot load /boot/vmlinuz-4.11.12+
>>
>
> Can you try below kexec-tools commit:
> commit ed15ba1b9977e506637ff1697821d97127b2c919
> Author: Pratyush Anand <panand at redhat.com>
> Date:   Wed Mar 1 11:19:42 2017 +0530
>
>     build_mem_phdrs(): check if p_paddr is invalid
>
> Thanks
> Dave
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec


From Anil.Gurumurthy at cavium.com  Wed Nov 29 02:06:14 2017
From: Anil.Gurumurthy at cavium.com (Gurumurthy, Anil)
Date: Wed, 29 Nov 2017 10:06:14 +0000
Subject: kdump issues with 4.11 kernel
In-Reply-To: <CACi5LpP9+5YVVh1DtnWXCMQbFMRJ1NVYh=_nQYcpShZS0es7hg@mail.gmail.com>
References: <BY2PR0701MB202342812CFB9669B01930D98E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <20171129073841.GA2129@dhcp-128-65.nay.redhat.com>
 <BY2PR0701MB2023DAF450CE2EB7270E05A38E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <CACi5LpP9+5YVVh1DtnWXCMQbFMRJ1NVYh=_nQYcpShZS0es7hg@mail.gmail.com>
Message-ID: <BY2PR0701MB2023FFA00EC7445B005BCB498E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>



-----Original Message-----
From: Bhupesh Sharma [mailto:bhsharma at redhat.com] 
Sent: 29 November 2017 15:16
To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
Cc: Dave Young <dyoung at redhat.com>; kexec at lists.infradead.org
Subject: Re: kdump issues with 4.11 kernel

Hi Anil,

On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil <Anil.Gurumurthy at cavium.com> wrote:
> Thanks. That did help getting kexec to work.
> However I still do not get a crash dump - echo c  > 
> /proc/sysrq-trigger does not get a crash dump.
>
> Any thoughts?

Cam you share the console messages you see when the crash kernel boots? Or do you see nothing after the crash is introduced via echo c
> /proc/sysrq-trigger
[Anil]  I do not see any messages after introducing the crash.

Generally, depending on your test machine arch, it is useful to use earlycon/earlyprintk to see if the crash kernel produced any useful message until the actual console device became operational.

Can you try setting the earlycon/earlyprintk settings and share the crash kernel logs messages after the same?

Thanks,
Bhupesh

> -----Original Message-----
> From: Dave Young [mailto:dyoung at redhat.com]
> Sent: 29 November 2017 13:09
> To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
> Cc: kexec at lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> Hi,
> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>> Hello,
>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>
>> [root at localhost ~]# kexec -p /boot/vmlinuz-`uname -r` 
>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse 
>> failed Cannot load /boot/vmlinuz-4.11.12+
>>
>
> Can you try below kexec-tools commit:
> commit ed15ba1b9977e506637ff1697821d97127b2c919
> Author: Pratyush Anand <panand at redhat.com>
> Date:   Wed Mar 1 11:19:42 2017 +0530
>
>     build_mem_phdrs(): check if p_paddr is invalid
>
> Thanks
> Dave
>
> _______________________________________________
> kexec mailing list
> kexec at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

From bhsharma at redhat.com  Wed Nov 29 02:19:45 2017
From: bhsharma at redhat.com (Bhupesh Sharma)
Date: Wed, 29 Nov 2017 15:49:45 +0530
Subject: kdump issues with 4.11 kernel
In-Reply-To: <BY2PR0701MB2023FFA00EC7445B005BCB498E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
References: <BY2PR0701MB202342812CFB9669B01930D98E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <20171129073841.GA2129@dhcp-128-65.nay.redhat.com>
 <BY2PR0701MB2023DAF450CE2EB7270E05A38E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <CACi5LpP9+5YVVh1DtnWXCMQbFMRJ1NVYh=_nQYcpShZS0es7hg@mail.gmail.com>
 <BY2PR0701MB2023FFA00EC7445B005BCB498E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
Message-ID: <CACi5LpNVRpHJW-AUuNnH0YQ-dTxD+fGjMAO_pL=2ieqzkG0mgw@mail.gmail.com>

On Wed, Nov 29, 2017 at 3:36 PM, Gurumurthy, Anil
<Anil.Gurumurthy at cavium.com> wrote:
>
>
> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma at redhat.com]
> Sent: 29 November 2017 15:16
> To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
> Cc: Dave Young <dyoung at redhat.com>; kexec at lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> Hi Anil,
>
> On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil <Anil.Gurumurthy at cavium.com> wrote:
>> Thanks. That did help getting kexec to work.
>> However I still do not get a crash dump - echo c  >
>> /proc/sysrq-trigger does not get a crash dump.
>>
>> Any thoughts?
>
> Cam you share the console messages you see when the crash kernel boots? Or do you see nothing after the crash is introduced via echo c
>> /proc/sysrq-trigger
> [Anil]  I do not see any messages after introducing the crash.

There could be several reasons for this:

- crashkernel might be missing some arch/machine specific options.
- It may be that the purgatory sha verification has failed. If your
arch supports a console in purgatory then it is easy to debug this.
- It might be that the crash kernel itself crashed very early. Pass
some earlycon/earlyprintk option for your system to the second kernel
command line.
- Also please share relevant dmesg log of both primary kernel boot and
the commands you use to invoke the crashkernel.

Regards,
Bhupesh


> Generally, depending on your test machine arch, it is useful to use earlycon/earlyprintk to see if the crash kernel produced any useful message until the actual console device became operational.
>
> Can you try setting the earlycon/earlyprintk settings and share the crash kernel logs messages after the same?
>
> Thanks,
> Bhupesh
>
>> -----Original Message-----
>> From: Dave Young [mailto:dyoung at redhat.com]
>> Sent: 29 November 2017 13:09
>> To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
>> Cc: kexec at lists.infradead.org
>> Subject: Re: kdump issues with 4.11 kernel
>>
>> Hi,
>> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>>> Hello,
>>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>>
>>> [root at localhost ~]# kexec -p /boot/vmlinuz-`uname -r`
>>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse
>>> failed Cannot load /boot/vmlinuz-4.11.12+
>>>
>>
>> Can you try below kexec-tools commit:
>> commit ed15ba1b9977e506637ff1697821d97127b2c919
>> Author: Pratyush Anand <panand at redhat.com>
>> Date:   Wed Mar 1 11:19:42 2017 +0530
>>
>>     build_mem_phdrs(): check if p_paddr is invalid
>>
>> Thanks
>> Dave
>>
>> _______________________________________________
>> kexec mailing list
>> kexec at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec


From Anil.Gurumurthy at cavium.com  Wed Nov 29 02:31:55 2017
From: Anil.Gurumurthy at cavium.com (Gurumurthy, Anil)
Date: Wed, 29 Nov 2017 10:31:55 +0000
Subject: kdump issues with 4.11 kernel
In-Reply-To: <CACi5LpNVRpHJW-AUuNnH0YQ-dTxD+fGjMAO_pL=2ieqzkG0mgw@mail.gmail.com>
References: <BY2PR0701MB202342812CFB9669B01930D98E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <20171129073841.GA2129@dhcp-128-65.nay.redhat.com>
 <BY2PR0701MB2023DAF450CE2EB7270E05A38E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <CACi5LpP9+5YVVh1DtnWXCMQbFMRJ1NVYh=_nQYcpShZS0es7hg@mail.gmail.com>
 <BY2PR0701MB2023FFA00EC7445B005BCB498E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <CACi5LpNVRpHJW-AUuNnH0YQ-dTxD+fGjMAO_pL=2ieqzkG0mgw@mail.gmail.com>
Message-ID: <BY2PR0701MB2023974CB792B56F110EC4BE8E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>



-----Original Message-----
From: Bhupesh Sharma [mailto:bhsharma at redhat.com] 
Sent: 29 November 2017 15:50
To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
Cc: Dave Young <dyoung at redhat.com>; kexec at lists.infradead.org
Subject: Re: kdump issues with 4.11 kernel

On Wed, Nov 29, 2017 at 3:36 PM, Gurumurthy, Anil <Anil.Gurumurthy at cavium.com> wrote:
>
>
> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma at redhat.com]
> Sent: 29 November 2017 15:16
> To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
> Cc: Dave Young <dyoung at redhat.com>; kexec at lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> Hi Anil,
>
> On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil <Anil.Gurumurthy at cavium.com> wrote:
>> Thanks. That did help getting kexec to work.
>> However I still do not get a crash dump - echo c  > 
>> /proc/sysrq-trigger does not get a crash dump.
>>
>> Any thoughts?
>
> Cam you share the console messages you see when the crash kernel 
> boots? Or do you see nothing after the crash is introduced via echo c
>> /proc/sysrq-trigger
> [Anil]  I do not see any messages after introducing the crash.

There could be several reasons for this:

- crashkernel might be missing some arch/machine specific options.
- It may be that the purgatory sha verification has failed. If your arch supports a console in purgatory then it is easy to debug this.
- It might be that the crash kernel itself crashed very early. Pass some earlycon/earlyprintk option for your system to the second kernel command line.
- Also please share relevant dmesg log of both primary kernel boot and the commands you use to invoke the crashkernel.

[Anil] Thanks for the quick response

   This is what I have in the .config (for the primary kernel)
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_EARLY_PRINTK_EFI=y

The log for the primary kernel boot:

Nov 29 14:22:22 localhost journal: Runtime journal is using 8.0M (max 1.9G, leaving 2.9G of free 19.4G, current limit 1.9G).
Nov 29 14:22:22 localhost kernel: Linux version 4.11.12+ (root at localhost.localdomain) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #4 SMP Thu Nov 23 12:11:02 IST 2017
Nov 29 14:22:22 localhost kernel: Command line: BOOT_IMAGE=/vmlinuz-4.11.12+ root=/dev/mapper/rhel-root ro rd.lvm.lv=rhel/swap crashkernel=128M rd.lvm.lv=rhel/root rhgb quiet
Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Nov 29 14:22:22 localhost kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Nov 29 14:22:22 localhost kernel: e820: BIOS-provided physical RAM map:
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000006bfff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000006c000-0x000000000006cfff] ACPI NVS
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000006d000-0x000000000009efff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] ACPI NVS
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x000000005d184fff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005d185000-0x000000005d185fff] ACPI data
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005d186000-0x000000005fb77fff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fb78000-0x000000005fb7cfff] reserved
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fb7d000-0x000000005ffdffff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005ffe0000-0x000000005ffe1fff] ACPI data
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005ffe2000-0x000000005fffafff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fffb000-0x0000000060001fff] ACPI data
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060002000-0x0000000060009fff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000006000a000-0x000000006000efff] ACPI data
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000006000f000-0x000000006000ffff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060010000-0x0000000060011fff] ACPI data
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060012000-0x00000000600ddfff] usable


Will try to get the other details you needed too.

-Anil

Regards,
Bhupesh


> Generally, depending on your test machine arch, it is useful to use earlycon/earlyprintk to see if the crash kernel produced any useful message until the actual console device became operational.
>
> Can you try setting the earlycon/earlyprintk settings and share the crash kernel logs messages after the same?
>
> Thanks,
> Bhupesh
>
>> -----Original Message-----
>> From: Dave Young [mailto:dyoung at redhat.com]
>> Sent: 29 November 2017 13:09
>> To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
>> Cc: kexec at lists.infradead.org
>> Subject: Re: kdump issues with 4.11 kernel
>>
>> Hi,
>> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>>> Hello,
>>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>>
>>> [root at localhost ~]# kexec -p /boot/vmlinuz-`uname -r` 
>>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse 
>>> failed Cannot load /boot/vmlinuz-4.11.12+
>>>
>>
>> Can you try below kexec-tools commit:
>> commit ed15ba1b9977e506637ff1697821d97127b2c919
>> Author: Pratyush Anand <panand at redhat.com>
>> Date:   Wed Mar 1 11:19:42 2017 +0530
>>
>>     build_mem_phdrs(): check if p_paddr is invalid
>>
>> Thanks
>> Dave
>>
>> _______________________________________________
>> kexec mailing list
>> kexec at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec

From jbohac at suse.cz  Wed Nov 29 04:27:32 2017
From: jbohac at suse.cz (Jiri Bohac)
Date: Wed, 29 Nov 2017 13:27:32 +0100
Subject: [PATCH] x86/kexec: Exclude GART aperture from vmcore
In-Reply-To: <20171129024307.GE15074@x1>
References: <20171106024143.GA3669@x1>
 <20171106090155.p7jhe2m57whfxma3@dwarf.suse.cz>
 <20171106092729.GB3669@x1>
 <20171106095638.7iwlyjmlom3tqelt@dwarf.suse.cz>
 <20171107113956.GC3669@x1>
 <20171107134212.tmjdt7rdailtbosa@dwarf.suse.cz>
 <20171107153428.ex27nwkvelhm2nm7@dwarf.suse.cz>
 <20171112080426.GB6429@x1>
 <20171128215833.hhcjvn5qjfc3bdrk@dwarf.suse.cz>
 <20171129024307.GE15074@x1>
Message-ID: <20171129122732.qcpi655yf26iuspg@dwarf.suse.cz>

On Wed, Nov 29, 2017 at 10:43:07AM +0800, Baoquan He wrote:
> On 11/28/17 at 10:58pm, Jiri Bohac wrote:
> > On Sun, Nov 12, 2017 at 04:04:26PM +0800, Baoquan He wrote:
> > > Solution:
> > > 1) Remove the code which support GART IOMMU when it's not enabled in
> > > BIOS. This has been done in the new generation of hardware IOMMU like
> > > intel vt-d IOMMU and amd-Vi IOMMU. We should not make GART IOMMU be
> > > exceptional.
> > 
> > Wouldn't this break old machines with actual AGP and
> > misconfigured/bugg BIOSes? Wasn't that the reason why we have the
> > workaround of mapping the hole over real memory?
> 
> Hmm, a quick question, does it work when GART support is enabled in
> bios? In intel vt-d and amd-vi iommu, if user doesn't enable it in bios,
> the functionality will be disabled in kernel, why would we not do that
> for GART IOMMU? and why is GART so special?

My feeling is that there is no technical reason (perhaps there
were more broken BIOSes in the AGP days?). The main reason is
that the kernel has included the workaround since ever and
removing it now will break these machines. Even if most of them
would be fixed by properly configuring the BIOS, it will still be
regardes as a regression by the user, which I don't think is
acceptable. 

Currently everything works with the workaround, except kdump.
That's why I came up with a fix for [half of] kdump.

> > > 2) Remove those pages from mm subsystem since they are not seen any more
> > > though they have been added into mm subsystem, because CPU can't see
> > > them.

Could you explain what exactly you mean and how it would fix the
vmcore issue? 

> > > 3) Remove the apreture region from /proc/iomem so that pages in that
> > > region can't be seen by kdump kernel. This is easier, but just a work
> > > around.
> > 
> > I like this idea, but won't this cause pci_claim_resource() fail
> > after the call to pci_find_parent_resource() ? See my previous
> > mail.
> 
> Not very sure, now have not time to investigate why it cause failure.
> 
> I tried to find a system with GART in our lab, but failed. Those
> machines are too old

The vmcore problem is reproducible on modern AMD systems. This
has originally been reported by a customer running an "HP ProLiant
BL465c Gen8". I later reproduced it on a "ProLiant DL385p Gen8",
as well as many older systems.

So I believe kdump/vmcore needs fixing - it is broken on machines
sold today.

What became a bit "old" is the reason why we don't include the
"GART" region in the iomem resources - fix for a resource
conflict resulting in malfuncioning AGP hardware as reported in
bko#72201; see my original mail for the full info. But I don't
think we should break this old hardware again just to make the
kdump fix more beautiful.

> If have a easy fix, worth to have a try.

The fix for kexec_file_load-based kdump is easy and tested. I
don't insist on fixing the old kexec, because we don't use it on
x86_64. But I'm willing to help if you think it needs to be fixed
as well.

Regards,

-- 
Jiri Bohac <jbohac at suse.cz>
SUSE Labs, Prague, Czechia



From eric.devolder at oracle.com  Wed Nov 29 08:45:16 2017
From: eric.devolder at oracle.com (Eric DeVolder)
Date: Wed, 29 Nov 2017 10:45:16 -0600
Subject: [PATCH v1] kexec-tools: Perform run-time linking of libxenctrl.so
Message-ID: <1511973916-3915-1-git-send-email-eric.devolder@oracle.com>

When kexec is utilized in a Xen environment, it has an explicit
run-time dependency on libxenctrl.so. This dependency occurs
during the configure stage and when building kexec-tools.

When kexec is utilized in a non-Xen environment (either bare
metal or KVM), the configure and build of kexec-tools omits
any reference to libxenctrl.so.

Thus today it is not currently possible to configure and build
a *single* kexec that will work in *both* Xen and non-Xen
environments, unless the libxenctrl.so is *always* present.

For example, a kexec configured for Xen in a Xen environment:

 # ldd build/sbin/kexec
        linux-vdso.so.1 =>  (0x00007ffdeba5c000)
        libxenctrl.so.4.4 => /usr/lib64/libxenctrl.so.4.4 (0x00000038d8000000)
        libz.so.1 => /lib64/libz.so.1 (0x00000038d6c00000)
        libc.so.6 => /lib64/libc.so.6 (0x00000038d6000000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00000038d6400000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00000038d6800000)
        /lib64/ld-linux-x86-64.so.2 (0x000055e9f8c6c000)
 # build/sbin/kexec -v
 kexec-tools 2.0.16

However, the *same* kexec executable fails in a non-Xen environment:

 # copy xen kexec to .
 # ldd ./kexec
         linux-vdso.so.1 =>  (0x00007fffa9da7000)
         libxenctrl.so.4.4 => not found
         liblzma.so.0 => /usr/lib64/liblzma.so.0 (0x0000003014e00000)
         libz.so.1 => /lib64/libz.so.1 (0x000000300ea00000)
         libc.so.6 => /lib64/libc.so.6 (0x000000300de00000)
         libpthread.so.0 => /lib64/libpthread.so.0 (0x000000300e200000)
         /lib64/ld-linux-x86-64.so.2 (0x0000558cc786c000)
 # ./kexec -v
 ./kexec: error while loading shared libraries:
 libxenctrl.so.4.4: cannot open shared object file: No such file or directory

At Oracle we "workaround" this by having two kexec-tools packages,
one for Xen and another for non-Xen environments. At Oracle, the
desire is to offer a single kexec-tools package that works in either
environment. To achieve this, kexec-tools would either have to ship
with libxenctrl.so (which we have deemed as unacceptable), or we can
make kexec perform run-time linking against libxenctrl.so.

This patch is one possible way to alleviate the explicit run-time
dependency on libxenctrl.so. This implementation utilizes a set of
macros to wrap calls into libxenctrl.so so that the library can
instead be dlopen() and obtain the function via dlsym() and then
make the call. The advantage of this implementation is that it
requires few changes to the existing kexec-tools code. The dis-
advantage is that it uses macros to remap libxenctrl functions
and do work under the hood.

Another possible implementation worth considering is the approach
taken by libvmi. Reference the following file:

https://github.com/libvmi/libvmi/blob/master/libvmi/driver/xen/libxc_wrapper.h

The libxc_wrapper_t structure definition that starts at line ~33
has members that are function pointers into libxenctrl.so. This
structure is populated once and then later referenced/dereferenced
by the callers of libxenctrl.so members. The advantage of this
implementation is it is more explicit in managing the use of
libxenctrl.so and its versions, but the disadvantage is it would
require touching more of the kexec-tools code.

The following is a list libxenctrl members utilized by kexec:

Functions:
xc_interface_open
xc_kexec_get_range
xc_interface_close
xc_kexec_get_range
xc_interface_open
xc_get_max_cpus
xc_kexec_get_range
xc_version
xc_kexec_exec
xc_kexec_status
xc_kexec_unload
xc_hypercall_buffer_array_create
xc__hypercall_buffer_array_alloc
xc_hypercall_buffer_array_destroy
xc_kexec_load
xc_get_machine_memory_map

Data:
xc__hypercall_buffer_HYPERCALL_BUFFER_NULL

These were identified by configuring and building kexec-tools
with Xen support, but omitting the -lxenctrl from the LDFLAGS
in the Makefile for an x86_64 build.

The above libxenctrl members were referenced via these source
files.

kexec/crashdump-xen.c
kexec/kexec-xen.c
kexec/arch/i386/kexec-x86-common.c
kexec/arch/i386/crashdump-x86.c

This patch provides a wrapper around the calls to the above
functions in libxenctrl.so. Every libxenctrl call must pass a
xc_interface which it obtains from xc_interface_open().
So the existing code is already structured in a manner that
facilitates graceful dlopen()'ing of the libxenctrl.so and
the subsequent dlsym() of the required member.

The patch creates a wrapper function around xc_interface_open()
and xc_interface_close() to perform the dlopen() and dlclose().

For the remaing xc_ functions, this patch defines a macro
of the same name which performs the dlsym() and then invokes
the function. See the _xc_call() macro for details.

There was one data item in libxenctrl.so that presented a
unique problem, HYPERCALL_BUFFER_NULL. It was only utilized
once, as

    set_xen_guest_handle(xen_segs[s].buf.h, HYPERCALL_BUFFER_NULL);

I tried a variety of techniques but could not find a general
macro-type solution without modifying xenctrl.h. So the
solution was to declare a local HYPERCALL_BUFFER_NULL, and
this appears to work. I admit I am not familiar with libxenctrl
to state if this is a satisfactory workaround, so feedback
here welcome. I can state that this allows kexec to load/unload/kexec
on Xen and non-Xen environments that I've tested without issue.

With this patch applied, kexec-tools can be built with Xen
support and yet there is no explicit run-time dependency on
libxenctrl.so. Thus it can also be deployed in non-Xen
environments where libxenctrl.so is not installed.

 # ldd build/sbin/kexec
        linux-vdso.so.1 =>  (0x00007fff7dbcd000)
        liblzma.so.0 => /usr/lib64/liblzma.so.0 (0x00000038d9000000)
        libz.so.1 => /lib64/libz.so.1 (0x00000038d6c00000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00000038d6400000)
        libc.so.6 => /lib64/libc.so.6 (0x00000038d6000000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00000038d6800000)
        /lib64/ld-linux-x86-64.so.2 (0x0000562dc0c14000)
 # build/sbin/kexec -v
 kexec-tools 2.0.16

Currently this feature is enabled with the following:

 ./configure --with-xen-dl --with-xen=no

This is a bit clunky. I welcome feedback such as better names
and/or usage of --with, as well as if we might make this feature
the default.

Signed-off-by: Eric DeVolder <eric.devolder at oracle.com>
---
 configure.ac                       | 18 ++++++++++++++
 kexec/Makefile                     |  1 +
 kexec/arch/i386/crashdump-x86.c    |  4 +---
 kexec/arch/i386/kexec-x86-common.c |  4 +---
 kexec/crashdump-xen.c              |  4 +---
 kexec/kexec-xen.c                  | 43 +++++++++++++++++++++++++++++++++-
 kexec/kexec-xen.h                  | 48 ++++++++++++++++++++++++++++++++++++++
 7 files changed, 112 insertions(+), 10 deletions(-)
 create mode 100644 kexec/kexec-xen.h

diff --git a/configure.ac b/configure.ac
index 208dc0a..4fc8aa0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -92,6 +92,9 @@ AC_ARG_WITH([lzma], AC_HELP_STRING([--without-lzma],[disable lzma support]),
 AC_ARG_WITH([xen], AC_HELP_STRING([--without-xen],
 	[disable extended xen support]), [ with_xen="$withval"], [ with_xen=yes ] )
 
+AC_ARG_WITH([xen-dl], AC_HELP_STRING([--without-xen-dl],
+	[link libxenctrl.so at run-time rather than build-time]), [ with_xen_dl="$withval"], [ with_xen_dl=no ] )
+
 AC_ARG_WITH([booke],
 		AC_HELP_STRING([--with-booke],[build for booke]),
 		AC_DEFINE(CONFIG_BOOKE,1,
@@ -174,6 +177,21 @@ if test "$with_xen" = yes ; then
 				AC_MSG_NOTICE([The kexec_status call is not available]))
 		fi
 fi
+if test "$with_xen_dl" = yes ; then
+	if test "$with_xen" = yes ; then
+		AC_MSG_ERROR([Options --with-xen and --with-xen-dl are mutually exclusive])
+	fi
+	AC_DEFINE(CONFIG_LIBXENCTRL_DL, 1, [Define to 1 to link libxenctrl.so at run-time rather than build-time])
+	AC_CHECK_HEADER(dlfcn.h, , AC_MSG_ERROR([Dynamic library linking not available]))
+	AC_CHECK_LIB(dl, dlopen, , AC_MSG_ERROR([Dynamic library linking not available]))
+	AC_CHECK_HEADER(xenctrl.h,
+		AC_DEFINE(HAVE_LIBXENCTRL, 1, [Define to 1 to enable run-time linking of libxenctrl.so]),
+		AC_MSG_ERROR([Xen support not available]))
+dnl NOTE: Explicitly *NOT* performing AC_CHECK_LIB(xenctrl) as only need the header file to build
+	AC_CHECK_HEADER(xenctrl.h,
+		AC_DEFINE(HAVE_KEXEC_CMD_STATUS, 1, [Define to 1 so kexec_status call is available]),
+		AC_MSG_NOTICE([The kexec_status call is not available]))
+fi
 
 dnl ---Sanity checks
 if test "$CC"      = "no"; then AC_MSG_ERROR([cc not found]); fi
diff --git a/kexec/Makefile b/kexec/Makefile
index 2b4fb3d..8871731 100644
--- a/kexec/Makefile
+++ b/kexec/Makefile
@@ -36,6 +36,7 @@ dist += kexec/Makefile						\
 	kexec/kexec-elf-boot.h					\
 	kexec/kexec-elf.h kexec/kexec-sha256.h			\
 	kexec/kexec-zlib.h kexec/kexec-lzma.h			\
+	kexec/kexec-xen.h 								\
 	kexec/kexec-syscall.h kexec/kexec.h kexec/kexec.8
 
 dist				+= kexec/proc_iomem.c
diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 69a063a..a948d9f 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -44,9 +44,7 @@
 #include "kexec-x86.h"
 #include "crashdump-x86.h"
 
-#ifdef HAVE_LIBXENCTRL
-#include <xenctrl.h>
-#endif /* HAVE_LIBXENCTRL */
+#include "../../kexec-xen.h"
 
 #include "x86-linux-setup.h"
 
diff --git a/kexec/arch/i386/kexec-x86-common.c b/kexec/arch/i386/kexec-x86-common.c
index be03618..b44c8b7 100644
--- a/kexec/arch/i386/kexec-x86-common.c
+++ b/kexec/arch/i386/kexec-x86-common.c
@@ -40,9 +40,7 @@
 #include "../../crashdump.h"
 #include "kexec-x86.h"
 
-#ifdef HAVE_LIBXENCTRL
-#include <xenctrl.h>
-#endif /* HAVE_LIBXENCTRL */
+#include "../../kexec-xen.h"
 
 /* Used below but not present in (older?) xenctrl.h */
 #ifndef E820_PMEM
diff --git a/kexec/crashdump-xen.c b/kexec/crashdump-xen.c
index 60594f6..2e4cbdc 100644
--- a/kexec/crashdump-xen.c
+++ b/kexec/crashdump-xen.c
@@ -18,9 +18,7 @@
 
 #include "config.h"
 
-#ifdef HAVE_LIBXENCTRL
-#include <xenctrl.h>
-#endif
+#include "kexec-xen.h"
 
 struct crash_note_info {
 	unsigned long base;
diff --git a/kexec/kexec-xen.c b/kexec/kexec-xen.c
index 2b448d3..2b01fee 100644
--- a/kexec/kexec-xen.c
+++ b/kexec/kexec-xen.c
@@ -10,10 +10,51 @@
 #include "config.h"
 
 #ifdef HAVE_LIBXENCTRL
-#include <xenctrl.h>
+#include "kexec-xen.h"
 
 #include "crashdump.h"
 
+#ifdef CONFIG_LIBXENCTRL_DL
+void *xc_dlhandle = NULL;
+xc_hypercall_buffer_t XC__HYPERCALL_BUFFER_NAME(HYPERCALL_BUFFER_NULL);
+xc_interface *_xc_interface_open(xentoollog_logger *logger,
+                                xentoollog_logger *dombuild_logger,
+                                unsigned open_flags)
+{
+    xc_interface *xch = NULL;
+
+    if (NULL == xc_dlhandle)
+        xc_dlhandle = dlopen("libxenctrl.so", RTLD_NOW | RTLD_NODELETE);
+
+    if (xc_dlhandle) {
+        typedef xc_interface *(*func_t)(xentoollog_logger *logger,
+                                xentoollog_logger *dombuild_logger,
+                                unsigned open_flags);
+        func_t func = (func_t)dlsym(xc_dlhandle, "xc_interface_open");
+        xch = func(logger, dombuild_logger, open_flags);
+    }
+
+    return xch;
+}
+
+int _xc_interface_close(xc_interface *xch)
+{
+    int rc = -1;
+
+/*
+    if (xc_dlhandle) {
+*/
+        typedef int (*func_t)(xc_interface *xch);
+        func_t func = (func_t)dlsym(xc_dlhandle, "xc_interface_close");
+        rc = func(xch);
+/*
+        xc_dlhandle = NULL;
+    }
+*/
+    return rc;
+}
+#endif /* CONFIG_LIBXENCTRL_DL */
+
 int xen_kexec_load(struct kexec_info *info)
 {
 	uint32_t nr_segments = info->nr_segments;
diff --git a/kexec/kexec-xen.h b/kexec/kexec-xen.h
new file mode 100644
index 0000000..6d2046e
--- /dev/null
+++ b/kexec/kexec-xen.h
@@ -0,0 +1,48 @@
+#ifndef KEXEC_XEN_H
+#define KEXEC_XEN_H
+
+#ifdef HAVE_LIBXENCTRL
+#include <xenctrl.h>
+
+#ifdef CONFIG_LIBXENCTRL_DL
+#include <dlfcn.h>
+
+/* The handle from dlopen(), needed by dlsym(), dlclose() */
+extern void *xc_dlhandle;
+
+/* Wrappers around xc_interface_open/close() to insert dlopen/dlclose() */
+xc_interface *_xc_interface_open(xentoollog_logger *logger,
+                                xentoollog_logger *dombuild_logger,
+                                unsigned open_flags);
+int _xc_interface_close(xc_interface *xch);
+
+/* GCC expression statements for evaluating dlsym() */
+#define _xc_call(DTYPE, NAME, ARGS...) ({ DTYPE value; typedef DTYPE (*func_t)(xc_interface *, ...); func_t func = dlsym(xc_dlhandle, #NAME); value = func(ARGS); value; } )
+#define _xc_data(DTYPE, NAME) ({ DTYPE *value = (DTYPE *)dlsym(xc_dlhandle, #NAME); value; } )
+
+/* The wrappers around utilized xenctrl.h functions */
+#define xc_interface_open(A,B,C)    _xc_interface_open(A,B,C)
+#define xc_interface_close(A)       _xc_interface_close(A)
+#define xc_version(ARGS...)         _xc_call(int, xc_version, ARGS)
+#define xc_get_max_cpus(ARGS...)    _xc_call(int, xc_get_max_cpus, ARGS)
+#define xc_get_machine_memory_map(ARGS...)  _xc_call(int, xc_get_machine_memory_map, ARGS)
+#define xc_kexec_get_range(ARGS...) _xc_call(int, xc_kexec_get_range, ARGS)
+#define xc_kexec_load(ARGS...)      _xc_call(int, xc_kexec_load, ARGS)
+#define xc_kexec_unload(ARGS...)    _xc_call(int, xc_kexec_unload, ARGS)
+#define xc_kexec_status(ARGS...)    _xc_call(int, xc_kexec_status, ARGS)
+#define xc_kexec_exec(ARGS...)      _xc_call(int, xc_kexec_exec, ARGS)
+#define xc_hypercall_buffer_array_create(ARGS...)   _xc_call(xc_hypercall_buffer_array_t *, xc_hypercall_buffer_array_create, ARGS)
+#define xc__hypercall_buffer_alloc(ARGS...) _xc_call(void *, xc__hypercall_buffer_alloc, ARGS)
+#define xc__hypercall_buffer_free(ARGS...)  _xc_call(void  , xc__hypercall_buffer_free, ARGS)
+#define xc__hypercall_buffer_alloc_pages(ARGS...)   _xc_call(void *, xc__hypercall_buffer_alloc_pages, ARGS)
+#define xc__hypercall_buffer_free_pages(ARGS...)    _xc_call(void  , xc__hypercall_buffer_free_pages, ARGS)
+#define xc__hypercall_buffer_array_alloc(ARGS...)   _xc_call(void *, xc__hypercall_buffer_array_alloc, ARGS)
+#define xc__hypercall_buffer_array_get(ARGS...)     _xc_call(void *, xc__hypercall_buffer_array_get, ARGS)
+#define xc_hypercall_buffer_array_destroy(ARGS...)  _xc_call(void *, xc_hypercall_buffer_array_destroy, ARGS)
+
+#endif /* CONFIG_LIBXENCTRL_DL */
+
+#endif /* HAVE_LIBXENCTRL */
+
+#endif /* KEXEC_XEN_H */
+
-- 
2.7.4



From Anil.Gurumurthy at cavium.com  Thu Nov 30 04:29:16 2017
From: Anil.Gurumurthy at cavium.com (Gurumurthy, Anil)
Date: Thu, 30 Nov 2017 12:29:16 +0000
Subject: kdump issues with 4.11 kernel
References: <BY2PR0701MB202342812CFB9669B01930D98E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <20171129073841.GA2129@dhcp-128-65.nay.redhat.com>
 <BY2PR0701MB2023DAF450CE2EB7270E05A38E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <CACi5LpP9+5YVVh1DtnWXCMQbFMRJ1NVYh=_nQYcpShZS0es7hg@mail.gmail.com>
 <BY2PR0701MB2023FFA00EC7445B005BCB498E3B0@BY2PR0701MB2023.namprd07.prod.outlook.com>
 <CACi5LpNVRpHJW-AUuNnH0YQ-dTxD+fGjMAO_pL=2ieqzkG0mgw@mail.gmail.com> 
Message-ID: <BY2PR0701MB202353AA68A956CA64516B808E380@BY2PR0701MB2023.namprd07.prod.outlook.com>

Hi Bhupesh,
  I tried to get some log messages for the crash kernel, but unable to get anything.
echo c > /proc/sysrq-trigger
simply hangs w/o any messages on the console.

Thanks,
Anil
-----Original Message-----
From: Gurumurthy, Anil 
Sent: 29 November 2017 16:02
To: 'Bhupesh Sharma' <bhsharma at redhat.com>
Cc: Dave Young <dyoung at redhat.com>; kexec at lists.infradead.org
Subject: RE: kdump issues with 4.11 kernel



-----Original Message-----
From: Bhupesh Sharma [mailto:bhsharma at redhat.com]
Sent: 29 November 2017 15:50
To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
Cc: Dave Young <dyoung at redhat.com>; kexec at lists.infradead.org
Subject: Re: kdump issues with 4.11 kernel

On Wed, Nov 29, 2017 at 3:36 PM, Gurumurthy, Anil <Anil.Gurumurthy at cavium.com> wrote:
>
>
> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma at redhat.com]
> Sent: 29 November 2017 15:16
> To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
> Cc: Dave Young <dyoung at redhat.com>; kexec at lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> Hi Anil,
>
> On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil <Anil.Gurumurthy at cavium.com> wrote:
>> Thanks. That did help getting kexec to work.
>> However I still do not get a crash dump - echo c  > 
>> /proc/sysrq-trigger does not get a crash dump.
>>
>> Any thoughts?
>
> Cam you share the console messages you see when the crash kernel 
> boots? Or do you see nothing after the crash is introduced via echo c
>> /proc/sysrq-trigger
> [Anil]  I do not see any messages after introducing the crash.

There could be several reasons for this:

- crashkernel might be missing some arch/machine specific options.
- It may be that the purgatory sha verification has failed. If your arch supports a console in purgatory then it is easy to debug this.
- It might be that the crash kernel itself crashed very early. Pass some earlycon/earlyprintk option for your system to the second kernel command line.
- Also please share relevant dmesg log of both primary kernel boot and the commands you use to invoke the crashkernel.

[Anil] Thanks for the quick response

   This is what I have in the .config (for the primary kernel) CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_EARLY_PRINTK_EFI=y

The log for the primary kernel boot:

Nov 29 14:22:22 localhost journal: Runtime journal is using 8.0M (max 1.9G, leaving 2.9G of free 19.4G, current limit 1.9G).
Nov 29 14:22:22 localhost kernel: Linux version 4.11.12+ (root at localhost.localdomain) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #4 SMP Thu Nov 23 12:11:02 IST 2017 Nov 29 14:22:22 localhost kernel: Command line: BOOT_IMAGE=/vmlinuz-4.11.12+ root=/dev/mapper/rhel-root ro rd.lvm.lv=rhel/swap crashkernel=128M rd.lvm.lv=rhel/root rhgb quiet Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256 Nov 29 14:22:22 localhost kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Nov 29 14:22:22 localhost kernel: e820: BIOS-provided physical RAM map:
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000006bfff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000006c000-0x000000000006cfff] ACPI NVS Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000006d000-0x000000000009efff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] ACPI NVS Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x000000005d184fff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005d185000-0x000000005d185fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005d186000-0x000000005fb77fff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fb78000-0x000000005fb7cfff] reserved Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fb7d000-0x000000005ffdffff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005ffe0000-0x000000005ffe1fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005ffe2000-0x000000005fffafff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fffb000-0x0000000060001fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060002000-0x0000000060009fff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000006000a000-0x000000006000efff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000006000f000-0x000000006000ffff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060010000-0x0000000060011fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060012000-0x00000000600ddfff] usable


Will try to get the other details you needed too.

-Anil

Regards,
Bhupesh


> Generally, depending on your test machine arch, it is useful to use earlycon/earlyprintk to see if the crash kernel produced any useful message until the actual console device became operational.
>
> Can you try setting the earlycon/earlyprintk settings and share the crash kernel logs messages after the same?
>
> Thanks,
> Bhupesh
>
>> -----Original Message-----
>> From: Dave Young [mailto:dyoung at redhat.com]
>> Sent: 29 November 2017 13:09
>> To: Gurumurthy, Anil <Anil.Gurumurthy at cavium.com>
>> Cc: kexec at lists.infradead.org
>> Subject: Re: kdump issues with 4.11 kernel
>>
>> Hi,
>> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>>> Hello,
>>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>>
>>> [root at localhost ~]# kexec -p /boot/vmlinuz-`uname -r` 
>>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse 
>>> failed Cannot load /boot/vmlinuz-4.11.12+
>>>
>>
>> Can you try below kexec-tools commit:
>> commit ed15ba1b9977e506637ff1697821d97127b2c919
>> Author: Pratyush Anand <panand at redhat.com>
>> Date:   Wed Mar 1 11:19:42 2017 +0530
>>
>>     build_mem_phdrs(): check if p_paddr is invalid
>>
>> Thanks
>> Dave
>>
>> _______________________________________________
>> kexec mailing list
>> kexec at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec

From daniel.kiper at oracle.com  Thu Nov 30 12:59:15 2017
From: daniel.kiper at oracle.com (Daniel Kiper)
Date: Thu, 30 Nov 2017 21:59:15 +0100
Subject: [PATCH v1] kexec-tools: Perform run-time linking of libxenctrl.so
In-Reply-To: <1511973916-3915-1-git-send-email-eric.devolder@oracle.com>
References: <1511973916-3915-1-git-send-email-eric.devolder@oracle.com>
Message-ID: <20171130205915.GB16962@olila.local.net-space.pl>

On Wed, Nov 29, 2017 at 10:45:16AM -0600, Eric DeVolder wrote:
> When kexec is utilized in a Xen environment, it has an explicit
> run-time dependency on libxenctrl.so. This dependency occurs
> during the configure stage and when building kexec-tools.
>
> When kexec is utilized in a non-Xen environment (either bare
> metal or KVM), the configure and build of kexec-tools omits
> any reference to libxenctrl.so.
>
> Thus today it is not currently possible to configure and build
> a *single* kexec that will work in *both* Xen and non-Xen
> environments, unless the libxenctrl.so is *always* present.

[...]

I will take a look at this next week.

Thanks,

Daniel


