All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_data
@ 2014-04-28  7:21 WANG Chao
  2014-04-28 13:26 ` [PATCH RESEND] " WANG Chao
  2014-04-28 13:29 ` [PATCH] " WANG Chao
  0 siblings, 2 replies; 4+ messages in thread
From: WANG Chao @ 2014-04-28  7:21 UTC (permalink / raw)
  To: horms; +Cc: kexec, cpw

e820 reserved region could be useful in 2nd kernel.

For example, PCI mmconf (extended mode) requires reserved region
otherwise it falls back to legacy mode. The following log is from Cliff
Wickman <cpw@sgi.com>:

 PCI: MMCONFIG for domain 1003 [bus 3f-3f] at [mem 0xff0ff00000-0xff0fffffff] (base 0xff0c000000)
 [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources
 PCI: not using MMCONFIG

PCI devices on segment 1 (>0) can't fall back to legacy mode, thus
kernel probing fails and device can't be found.

We don't pass reserved region because these regions could be too much
and eat up our very limited kernel command line resource in
memmap=exactmap case.

However now we use e820 map and setup_data to pass memory map to 2nd
kernel and the number of reserved regions should not be a problem any
more.

Signed-off-by: WANG Chao <chaowang@redhat.com>
---
 kexec/arch/i386/crashdump-x86.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 4a1491b..321ed3d 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -300,6 +300,9 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 			type = RANGE_ACPI;
 		} else if(memcmp(str,"ACPI Non-volatile Storage\n",26) == 0 ) {
 			type = RANGE_ACPI_NVS;
+		} else if(memcmp(str,"reserved\n",9) == 0 ) {
+			type = RANGE_RANGE;
+		} else if (memcmp(str, "GART\n", 5) == 0) {
 		} else if (memcmp(str, "GART\n", 5) == 0) {
 			gart_start = start;
 			gart_end = end;
@@ -989,14 +992,15 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 	for (i = 0; i < CRASH_MAX_MEMORY_RANGES; i++) {
 		unsigned long start, end, size, type;
 		if ( !( mem_range[i].type == RANGE_ACPI
-			|| mem_range[i].type == RANGE_ACPI_NVS) )
+			|| mem_range[i].type == RANGE_ACPI_NVS
+			|| mem_range[i].type == RANGE_RESERVED))
 			continue;
 		start = mem_range[i].start;
 		end = mem_range[i].end;
 		type = mem_range[i].type;
 		size = end - start + 1;
 		add_memmap(memmap_p, &nr_memmap, start, size, type);
-		if (arch_options.pass_memmap_cmdline)
+		if (arch_options.pass_memmap_cmdline || type != RANGE_RESERVED)
 			cmdline_add_memmap_acpi(mod_cmdline, start, end);
 	}
 
-- 
1.9.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* [PATCH RESEND] kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_data
  2014-04-28  7:21 [PATCH] kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_data WANG Chao
@ 2014-04-28 13:26 ` WANG Chao
  2014-04-29  1:59   ` Simon Horman
  2014-04-28 13:29 ` [PATCH] " WANG Chao
  1 sibling, 1 reply; 4+ messages in thread
From: WANG Chao @ 2014-04-28 13:26 UTC (permalink / raw)
  To: horms; +Cc: kexec, cpw

e820 reserved region could be useful in 2nd kernel.

For example, PCI mmconf (extended mode) requires reserved region
otherwise it falls back to legacy mode. The following log is from Cliff
Wickman <cpw@sgi.com>:

 PCI: MMCONFIG for domain 1003 [bus 3f-3f] at [mem 0xff0ff00000-0xff0fffffff] (base 0xff0c000000)
 [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources
 PCI: not using MMCONFIG

PCI devices on segment 1 (>0) can't fall back to legacy mode, thus
kernel probing fails and device can't be found.

We don't pass reserved region because these regions could be too much
and eat up our very limited kernel command line resource in
memmap=exactmap case.

However now we use e820 map and setup_data to pass memory map to 2nd
kernel and the number of reserved regions should not be a problem any
more.

Signed-off-by: WANG Chao <chaowang@redhat.com>
---
 kexec/arch/i386/crashdump-x86.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
index 4a1491b..cc33347 100644
--- a/kexec/arch/i386/crashdump-x86.c
+++ b/kexec/arch/i386/crashdump-x86.c
@@ -300,6 +300,9 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
 			type = RANGE_ACPI;
 		} else if(memcmp(str,"ACPI Non-volatile Storage\n",26) == 0 ) {
 			type = RANGE_ACPI_NVS;
+		} else if(memcmp(str,"reserved\n",9) == 0 ) {
+			type = RANGE_RESERVED;
+		} else if (memcmp(str, "GART\n", 5) == 0) {
 		} else if (memcmp(str, "GART\n", 5) == 0) {
 			gart_start = start;
 			gart_end = end;
@@ -989,14 +992,15 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 	for (i = 0; i < CRASH_MAX_MEMORY_RANGES; i++) {
 		unsigned long start, end, size, type;
 		if ( !( mem_range[i].type == RANGE_ACPI
-			|| mem_range[i].type == RANGE_ACPI_NVS) )
+			|| mem_range[i].type == RANGE_ACPI_NVS
+			|| mem_range[i].type == RANGE_RESERVED))
 			continue;
 		start = mem_range[i].start;
 		end = mem_range[i].end;
 		type = mem_range[i].type;
 		size = end - start + 1;
 		add_memmap(memmap_p, &nr_memmap, start, size, type);
-		if (arch_options.pass_memmap_cmdline)
+		if (arch_options.pass_memmap_cmdline || type != RANGE_RESERVED)
 			cmdline_add_memmap_acpi(mod_cmdline, start, end);
 	}
 
-- 
1.9.0


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_data
  2014-04-28  7:21 [PATCH] kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_data WANG Chao
  2014-04-28 13:26 ` [PATCH RESEND] " WANG Chao
@ 2014-04-28 13:29 ` WANG Chao
  1 sibling, 0 replies; 4+ messages in thread
From: WANG Chao @ 2014-04-28 13:29 UTC (permalink / raw)
  To: horms; +Cc: kexec, cpw

On 04/28/14 at 03:21pm, WANG Chao wrote:
> e820 reserved region could be useful in 2nd kernel.
> 
> For example, PCI mmconf (extended mode) requires reserved region
> otherwise it falls back to legacy mode. The following log is from Cliff
> Wickman <cpw@sgi.com>:
> 
>  PCI: MMCONFIG for domain 1003 [bus 3f-3f] at [mem 0xff0ff00000-0xff0fffffff] (base 0xff0c000000)
>  [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources
>  PCI: not using MMCONFIG
> 
> PCI devices on segment 1 (>0) can't fall back to legacy mode, thus
> kernel probing fails and device can't be found.
> 
> We don't pass reserved region because these regions could be too much
> and eat up our very limited kernel command line resource in
> memmap=exactmap case.
> 
> However now we use e820 map and setup_data to pass memory map to 2nd
> kernel and the number of reserved regions should not be a problem any
> more.
> 
> Signed-off-by: WANG Chao <chaowang@redhat.com>
> ---
>  kexec/arch/i386/crashdump-x86.c | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
> index 4a1491b..321ed3d 100644
> --- a/kexec/arch/i386/crashdump-x86.c
> +++ b/kexec/arch/i386/crashdump-x86.c
> @@ -300,6 +300,9 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges,
>  			type = RANGE_ACPI;
>  		} else if(memcmp(str,"ACPI Non-volatile Storage\n",26) == 0 ) {
>  			type = RANGE_ACPI_NVS;
> +		} else if(memcmp(str,"reserved\n",9) == 0 ) {
> +			type = RANGE_RANGE;

This is wrong. I've resend the correct one.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH RESEND] kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_data
  2014-04-28 13:26 ` [PATCH RESEND] " WANG Chao
@ 2014-04-29  1:59   ` Simon Horman
  0 siblings, 0 replies; 4+ messages in thread
From: Simon Horman @ 2014-04-29  1:59 UTC (permalink / raw)
  To: WANG Chao; +Cc: kexec, cpw

On Mon, Apr 28, 2014 at 09:26:11PM +0800, WANG Chao wrote:
> e820 reserved region could be useful in 2nd kernel.
> 
> For example, PCI mmconf (extended mode) requires reserved region
> otherwise it falls back to legacy mode. The following log is from Cliff
> Wickman <cpw@sgi.com>:
> 
>  PCI: MMCONFIG for domain 1003 [bus 3f-3f] at [mem 0xff0ff00000-0xff0fffffff] (base 0xff0c000000)
>  [Firmware Bug]: PCI: MMCONFIG at [mem 0x80000000-0x80cfffff] not reserved in ACPI motherboard resources
>  PCI: not using MMCONFIG
> 
> PCI devices on segment 1 (>0) can't fall back to legacy mode, thus
> kernel probing fails and device can't be found.
> 
> We don't pass reserved region because these regions could be too much
> and eat up our very limited kernel command line resource in
> memmap=exactmap case.
> 
> However now we use e820 map and setup_data to pass memory map to 2nd
> kernel and the number of reserved regions should not be a problem any
> more.
> 
> Signed-off-by: WANG Chao <chaowang@redhat.com>

Thanks, applied.

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-04-29  2:00 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-28  7:21 [PATCH] kdump: pass e820 reserved region to 2nd kernel via e820 table or setup_data WANG Chao
2014-04-28 13:26 ` [PATCH RESEND] " WANG Chao
2014-04-29  1:59   ` Simon Horman
2014-04-28 13:29 ` [PATCH] " WANG Chao

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.