[PATCH 0/4] kexec-tools: mips: Fixes for 64-bit and OCTEON

[PATCH 0/4] kexec-tools: mips: Fixes for 64-bit and OCTEON

[David Daney]

Here are a few improvements to the kexec-tools needed to get usable
core dumps out of 64-bit kernels running on Cavium's OCTEON
processors.  Patch 3/4 is OCTEON specific, the rest are needed for
good results on MIPS64 in general.

David Daney (4):
  kexec-tools: mips: Merge adjacent memory ranges.
  kexec-tools: mips: Don't set lowmem_limit to 2G for 64-bit systems.
  kexec-tools: mips: Use proper page_offset for OCTEON CPUs.
  kexec-tools: mips: Try to include bss in kernel vmcore file.

 kexec/arch/mips/crashdump-mips.c | 36 +++++++++++++++++++++++++++++++++---
 kexec/arch/mips/crashdump-mips.h |  3 ++-
 kexec/arch/mips/kexec-mips.c     | 14 ++++++++++----
 3 files changed, 45 insertions(+), 8 deletions(-)

-- 
2.9.5

[PATCH 1/4] kexec-tools: mips: Merge adjacent memory ranges.

[David Daney]

Some kernel versions running on MIPS split the System RAM memory
regions reported in /proc/iomem.  This may cause loading of the kexec
kernel to fail if it crosses one of the splits.

Fix by merging adjacent memory ranges that have the same type.

Signed-off-by: David Daney <david.daney@cavium.com>
---
 kexec/arch/mips/kexec-mips.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/kexec/arch/mips/kexec-mips.c b/kexec/arch/mips/kexec-mips.c
index 2e5b700..415c2ed 100644
--- a/kexec/arch/mips/kexec-mips.c
+++ b/kexec/arch/mips/kexec-mips.c
@@ -60,10 +60,16 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
 		} else {
 			continue;
 		}
-		memory_range[memory_ranges].start = start;
-		memory_range[memory_ranges].end = end;
-		memory_range[memory_ranges].type = type;
-		memory_ranges++;
+		if (memory_ranges > 0 &&
+		    memory_range[memory_ranges - 1].end == start &&
+		    memory_range[memory_ranges - 1].type == type) {
+			memory_range[memory_ranges - 1].end = end;
+		} else {
+			memory_range[memory_ranges].start = start;
+			memory_range[memory_ranges].end = end;
+			memory_range[memory_ranges].type = type;
+			memory_ranges++;
+		}
 	}
 	fclose(fp);
 	*range = memory_range;
-- 
2.9.5

[PATCH 2/4] kexec-tools: mips: Don't set lowmem_limit to 2G for 64-bit systems.

[David Daney]

The 64-bit MIPS architecture doesn't have the same 2G limit the 32-bit
version has.  Set MAXMEM and lowmem_limit to 0 for 64-bit MIPS so that
memory above 2G is usable in the kdump core files.

Signed-off-by: David Daney <david.daney@cavium.com>
---
 kexec/arch/mips/crashdump-mips.c | 4 ++--
 kexec/arch/mips/crashdump-mips.h | 3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/kexec/arch/mips/crashdump-mips.c b/kexec/arch/mips/crashdump-mips.c
index 6308ec8..22fc38e 100644
--- a/kexec/arch/mips/crashdump-mips.c
+++ b/kexec/arch/mips/crashdump-mips.c
@@ -201,7 +201,7 @@ static int get_crash_memory_ranges(struct memory_range **range, int *ranges)
 		memory_ranges++;
 
 		/* Segregate linearly mapped region. */
-		if ((MAXMEM - 1) >= start && (MAXMEM - 1) <= end) {
+		if (MAXMEM && (MAXMEM - 1) >= start && (MAXMEM - 1) <= end) {
 			crash_memory_range[memory_ranges - 1].end = MAXMEM - 1;
 
 			/* Add segregated region. */
@@ -304,7 +304,7 @@ static struct crash_elf_info elf_info64 = {
 	data : ELFDATALOCAL,
 	machine : EM_MIPS,
 	page_offset : PAGE_OFFSET,
-	lowmem_limit : MAXMEM,
+	lowmem_limit : 0, /* 0 == no limit */
 };
 
 static struct crash_elf_info elf_info32 = {
diff --git a/kexec/arch/mips/crashdump-mips.h b/kexec/arch/mips/crashdump-mips.h
index c986835..7edd859 100644
--- a/kexec/arch/mips/crashdump-mips.h
+++ b/kexec/arch/mips/crashdump-mips.h
@@ -6,12 +6,13 @@ int load_crashdump_segments(struct kexec_info *info, char *mod_cmdline,
 				unsigned long max_addr, unsigned long min_base);
 #ifdef __mips64
 #define PAGE_OFFSET	0xa800000000000000ULL
+#define MAXMEM		0
 #else
 #define PAGE_OFFSET	0x80000000
+#define MAXMEM		0x80000000
 #endif
 #define __pa(x)		((unsigned long)(X) & 0x7fffffff)
 
-#define MAXMEM		0x80000000
 
 #define CRASH_MAX_MEMMAP_NR	(KEXEC_MAX_SEGMENTS + 1)
 #define CRASH_MAX_MEMORY_RANGES	(MAX_MEMORY_RANGES + 2)
-- 
2.9.5

[PATCH 3/4] kexec-tools: mips: Use proper page_offset for OCTEON CPUs.

[David Daney]

The OCTEON family of MIPS64 CPUs uses a PAGE_OFFSET of
0x8000000000000000ULL, which is differs from other CPUs.

Scan /proc/cpuinfo to see if the current system is "Octeon", if so,
patch the page_offset so that usable kdump core files are produced.

Signed-off-by: David Daney <david.daney@cavium.com>
---
 kexec/arch/mips/crashdump-mips.c | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/kexec/arch/mips/crashdump-mips.c b/kexec/arch/mips/crashdump-mips.c
index 22fc38e..e98badf 100644
--- a/kexec/arch/mips/crashdump-mips.c
+++ b/kexec/arch/mips/crashdump-mips.c
@@ -315,6 +315,30 @@ static struct crash_elf_info elf_info32 = {
 	lowmem_limit : MAXMEM,
 };
 
+static int patch_elf_info(void)
+{
+	const char cpuinfo[] = "/proc/cpuinfo";
+	char line[MAX_LINE];
+	FILE *fp;
+
+	fp = fopen(cpuinfo, "r");
+	if (!fp) {
+		fprintf(stderr, "Cannot open %s: %s\n",
+			cpuinfo, strerror(errno));
+		return -1;
+	}
+	while (fgets(line, sizeof(line), fp) != 0) {
+		if (strncmp(line, "cpu model", 9) == 0) {
+			/* OCTEON uses a different page_offset. */
+			if (strstr(line, "Octeon"))
+				elf_info64.page_offset = 0x8000000000000000ULL;
+			break;
+		}
+	}
+	fclose(fp);
+	return 0;
+}
+
 /* Loads additional segments in case of a panic kernel is being loaded.
  * One segment for backup region, another segment for storing elf headers
  * for crash memory image.
@@ -331,6 +355,9 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
 	struct crash_elf_info *elf_info = &elf_info32;
 	unsigned long start_offset = 0x80000000UL;
 
+	if (patch_elf_info())
+		return -1;
+
 	if (arch_options.core_header_type == CORE_TYPE_ELF64) {
 		elf_info = &elf_info64;
 		crash_create = crash_create_elf64_headers;
-- 
2.9.5

[PATCH 4/4] kexec-tools: mips: Try to include bss in kernel vmcore file.

[David Daney]

The kernel message buffers, as well as a lot of other useful data
reside in the bss section.  Without this vmcore-dmesg cannot work, and
debugging with a core dump is much more difficult.

Try to add the /proc/iomem "Kernel bss" section to vmcore.  If it is
not found, just do what we used to do and use "Kernel data" instead.

Signed-off-by: David Daney <david.daney@cavium.com>
---
 kexec/arch/mips/crashdump-mips.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kexec/arch/mips/crashdump-mips.c b/kexec/arch/mips/crashdump-mips.c
index e98badf..fc92e64 100644
--- a/kexec/arch/mips/crashdump-mips.c
+++ b/kexec/arch/mips/crashdump-mips.c
@@ -74,7 +74,10 @@ static int get_kernel_vaddr_and_size(struct crash_elf_info *elf_info,
 
 	elf_info->kern_vaddr_start = elf_info->kern_paddr_start |
 					start_offset;
-	if (parse_iomem_single("Kernel data\n", NULL, &end) == 0) {
+	/* If "Kernel bss" exists, the kernel ends there, else fall
+	 *  through and say that it ends at "Kernel data" */
+	if (parse_iomem_single("Kernel bss\n", NULL, &end) == 0 ||
+	    parse_iomem_single("Kernel data\n", NULL, &end) == 0) {
 		elf_info->kern_size = end - elf_info->kern_paddr_start;
 		dbgprintf("kernel_vaddr= 0x%llx paddr %llx\n",
 				elf_info->kern_vaddr_start,
-- 
2.9.5

Re: [PATCH 1/4] kexec-tools: mips: Merge adjacent memory ranges.

[Simon Horman]

On Thu, Oct 12, 2017 at 02:02:25PM -0700, David Daney wrote:
> Some kernel versions running on MIPS split the System RAM memory
> regions reported in /proc/iomem.  This may cause loading of the kexec
> kernel to fail if it crosses one of the splits.
> 
> Fix by merging adjacent memory ranges that have the same type.
> 
> Signed-off-by: David Daney <david.daney@cavium.com>
> ---
>  kexec/arch/mips/kexec-mips.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/kexec/arch/mips/kexec-mips.c b/kexec/arch/mips/kexec-mips.c
> index 2e5b700..415c2ed 100644
> --- a/kexec/arch/mips/kexec-mips.c
> +++ b/kexec/arch/mips/kexec-mips.c
> @@ -60,10 +60,16 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>  		} else {
>  			continue;
>  		}
> -		memory_range[memory_ranges].start = start;
> -		memory_range[memory_ranges].end = end;
> -		memory_range[memory_ranges].type = type;
> -		memory_ranges++;
> +		if (memory_ranges > 0 &&

It seems that this will never merge the first memory range
with subsequent ones. Is that intentional?


> +		    memory_range[memory_ranges - 1].end == start &&
> +		    memory_range[memory_ranges - 1].type == type) {
> +			memory_range[memory_ranges - 1].end = end;
> +		} else {
> +			memory_range[memory_ranges].start = start;
> +			memory_range[memory_ranges].end = end;
> +			memory_range[memory_ranges].type = type;
> +			memory_ranges++;
> +		}
>  	}
>  	fclose(fp);
>  	*range = memory_range;
> -- 
> 2.9.5
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

Re: [PATCH 3/4] kexec-tools: mips: Use proper page_offset for OCTEON CPUs.

[Simon Horman]

On Thu, Oct 12, 2017 at 02:02:27PM -0700, David Daney wrote:
> The OCTEON family of MIPS64 CPUs uses a PAGE_OFFSET of
> 0x8000000000000000ULL, which is differs from other CPUs.
> 
> Scan /proc/cpuinfo to see if the current system is "Octeon", if so,
> patch the page_offset so that usable kdump core files are produced.
> 
> Signed-off-by: David Daney <david.daney@cavium.com>

Is it possible to read this offset from the system rather than
checking for an Octeon CPU? It seems that such an approach, if possible,
would be somewhat more general.

Re: [PATCH 2/4] kexec-tools: mips: Don't set lowmem_limit to 2G for 64-bit systems.

[Simon Horman]

On Thu, Oct 12, 2017 at 02:02:26PM -0700, David Daney wrote:
> The 64-bit MIPS architecture doesn't have the same 2G limit the 32-bit
> version has.  Set MAXMEM and lowmem_limit to 0 for 64-bit MIPS so that
> memory above 2G is usable in the kdump core files.
> 
> Signed-off-by: David Daney <david.daney@cavium.com>

Thanks, applied.

Re: [PATCH 4/4] kexec-tools: mips: Try to include bss in kernel vmcore file.

[Simon Horman]

On Thu, Oct 12, 2017 at 02:02:28PM -0700, David Daney wrote:
> The kernel message buffers, as well as a lot of other useful data
> reside in the bss section.  Without this vmcore-dmesg cannot work, and
> debugging with a core dump is much more difficult.
> 
> Try to add the /proc/iomem "Kernel bss" section to vmcore.  If it is
> not found, just do what we used to do and use "Kernel data" instead.

Thanks, applied.

Re: [PATCH 3/4] kexec-tools: mips: Use proper page_offset for OCTEON CPUs.

[David Daney]

On 10/15/2017 11:56 PM, Simon Horman wrote:
> On Thu, Oct 12, 2017 at 02:02:27PM -0700, David Daney wrote:
>> The OCTEON family of MIPS64 CPUs uses a PAGE_OFFSET of
>> 0x8000000000000000ULL, which is differs from other CPUs.
>>
>> Scan /proc/cpuinfo to see if the current system is "Octeon", if so,
>> patch the page_offset so that usable kdump core files are produced.
>>
>> Signed-off-by: David Daney <david.daney@cavium.com>
> 
> Is it possible to read this offset from the system rather than
> checking for an Octeon CPU? It seems that such an approach, if possible,
> would be somewhat more general.
> 

Before implementing this scanning of /proc/cpuinfo, I thought long and 
hard about this, and couldn't think of how the PAGE_OFFSET could be 
derived from information available in userspace.

Ralf (MIPS maintainer) may have an idea, but these address bits don't 
show up in /proc/kallsyms or any other file in /proc or /sys that I am 
aware of.

David

Re: [PATCH 1/4] kexec-tools: mips: Merge adjacent memory ranges.

[David Daney]

On 10/15/2017 11:53 PM, Simon Horman wrote:
> On Thu, Oct 12, 2017 at 02:02:25PM -0700, David Daney wrote:
>> Some kernel versions running on MIPS split the System RAM memory
>> regions reported in /proc/iomem.  This may cause loading of the kexec
>> kernel to fail if it crosses one of the splits.
>>
>> Fix by merging adjacent memory ranges that have the same type.
>>
>> Signed-off-by: David Daney <david.daney@cavium.com>
>> ---
>>   kexec/arch/mips/kexec-mips.c | 14 ++++++++++----
>>   1 file changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/kexec/arch/mips/kexec-mips.c b/kexec/arch/mips/kexec-mips.c
>> index 2e5b700..415c2ed 100644
>> --- a/kexec/arch/mips/kexec-mips.c
>> +++ b/kexec/arch/mips/kexec-mips.c
>> @@ -60,10 +60,16 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
>>   		} else {
>>   			continue;
>>   		}
>> -		memory_range[memory_ranges].start = start;
>> -		memory_range[memory_ranges].end = end;
>> -		memory_range[memory_ranges].type = type;
>> -		memory_ranges++;
>> +		if (memory_ranges > 0 &&
> 
> It seems that this will never merge the first memory range
> with subsequent ones. Is that intentional?


With the first range (index 0), no other range yet exists to merge with. 
  We can only test for merging with the second and subsequent ranges 
(indices 1 and above).  To do otherwise would cause us to read things 
from *before* the beginning of the array ...

> 
> 
>> +		    memory_range[memory_ranges - 1].end == start &&

... here.

>> +		    memory_range[memory_ranges - 1].type == type) {
>> +			memory_range[memory_ranges - 1].end = end;
>> +		} else {
>> +			memory_range[memory_ranges].start = start;
>> +			memory_range[memory_ranges].end = end;
>> +			memory_range[memory_ranges].type = type;
>> +			memory_ranges++;
>> +		}
>>   	}
>>   	fclose(fp);
>>   	*range = memory_range;
>> -- 
>> 2.9.5
>>
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
>>

Re: [PATCH 1/4] kexec-tools: mips: Merge adjacent memory ranges.

[Simon Horman]

On Mon, Oct 16, 2017 at 09:13:30AM -0700, David Daney wrote:
> On 10/15/2017 11:53 PM, Simon Horman wrote:
> > On Thu, Oct 12, 2017 at 02:02:25PM -0700, David Daney wrote:
> > > Some kernel versions running on MIPS split the System RAM memory
> > > regions reported in /proc/iomem.  This may cause loading of the kexec
> > > kernel to fail if it crosses one of the splits.
> > > 
> > > Fix by merging adjacent memory ranges that have the same type.
> > > 
> > > Signed-off-by: David Daney <david.daney@cavium.com>
> > > ---
> > >   kexec/arch/mips/kexec-mips.c | 14 ++++++++++----
> > >   1 file changed, 10 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/kexec/arch/mips/kexec-mips.c b/kexec/arch/mips/kexec-mips.c
> > > index 2e5b700..415c2ed 100644
> > > --- a/kexec/arch/mips/kexec-mips.c
> > > +++ b/kexec/arch/mips/kexec-mips.c
> > > @@ -60,10 +60,16 @@ int get_memory_ranges(struct memory_range **range, int *ranges,
> > >   		} else {
> > >   			continue;
> > >   		}
> > > -		memory_range[memory_ranges].start = start;
> > > -		memory_range[memory_ranges].end = end;
> > > -		memory_range[memory_ranges].type = type;
> > > -		memory_ranges++;
> > > +		if (memory_ranges > 0 &&
> > 
> > It seems that this will never merge the first memory range
> > with subsequent ones. Is that intentional?
> 
> 
> With the first range (index 0), no other range yet exists to merge with.  We
> can only test for merging with the second and subsequent ranges (indices 1
> and above).  To do otherwise would cause us to read things from *before* the
> beginning of the array ...

Yes, of course. I see that now.

I've applied this patch.

> > 
> > 
> > > +		    memory_range[memory_ranges - 1].end == start &&
> 
> ... here.
> 
> > > +		    memory_range[memory_ranges - 1].type == type) {
> > > +			memory_range[memory_ranges - 1].end = end;
> > > +		} else {
> > > +			memory_range[memory_ranges].start = start;
> > > +			memory_range[memory_ranges].end = end;
> > > +			memory_range[memory_ranges].type = type;
> > > +			memory_ranges++;
> > > +		}
> > >   	}
> > >   	fclose(fp);
> > >   	*range = memory_range;
> > > -- 
> > > 2.9.5
> > > 
> > > 
> > > _______________________________________________
> > > kexec mailing list
> > > kexec@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/kexec
> > > 
> 
> 
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
> 

Re: [PATCH 3/4] kexec-tools: mips: Use proper page_offset for OCTEON CPUs.

[Simon Horman]

On Mon, Oct 16, 2017 at 09:05:22AM -0700, David Daney wrote:
> On 10/15/2017 11:56 PM, Simon Horman wrote:
> > On Thu, Oct 12, 2017 at 02:02:27PM -0700, David Daney wrote:
> > > The OCTEON family of MIPS64 CPUs uses a PAGE_OFFSET of
> > > 0x8000000000000000ULL, which is differs from other CPUs.
> > > 
> > > Scan /proc/cpuinfo to see if the current system is "Octeon", if so,
> > > patch the page_offset so that usable kdump core files are produced.
> > > 
> > > Signed-off-by: David Daney <david.daney@cavium.com>
> > 
> > Is it possible to read this offset from the system rather than
> > checking for an Octeon CPU? It seems that such an approach, if possible,
> > would be somewhat more general.
> > 
> 
> Before implementing this scanning of /proc/cpuinfo, I thought long and hard
> about this, and couldn't think of how the PAGE_OFFSET could be derived from
> information available in userspace.
> 
> Ralf (MIPS maintainer) may have an idea, but these address bits don't show
> up in /proc/kallsyms or any other file in /proc or /sys that I am aware of.

Thanks for the explanation. I've applied this patch pending any further
progress in this area.