[PATCH] Crash-Utility: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
4:09 a.m.
From: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
So far s390x kernel was using 42 bits for MAX_PHYSMEM_BITS that use to
support maximum of 4TB of memory. In order to support bigger systems,
the newer s390x kernel will now use 46 bits for MAX_PHYSMEM_BITS to support
maximum of 64TB of memory.
This patch enhances crash utility to auto-detect the correct value to use
for MAX_PHYSMEM_BITS by examining the mem_section array size from the vmcore
being analyzed.
Signed-off-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
---
defs.h | 3 ++-
s390x.c | 26 +++++++++++++++++++++++++-
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/defs.h b/defs.h
index 381e8c2..eb992d1 100755
--- a/defs.h
+++ b/defs.h
@@ -2954,7 +2954,8 @@ struct efi_memory_desc_t {
#define TIF_SIGPENDING (2)
#define _SECTION_SIZE_BITS 28
-#define _MAX_PHYSMEM_BITS 42
+#define _MAX_PHYSMEM_BITS_OLD 42
+#define _MAX_PHYSMEM_BITS_NEW 46
#endif /* S390X */
diff --git a/s390x.c b/s390x.c
index 22e29a9..53bf272 100755
--- a/s390x.c
+++ b/s390x.c
@@ -282,6 +282,29 @@ static void s390x_process_elf_notes(void *note_ptr, unsigned long
size_note)
}
}
+static int
+set_s390x_max_physmem_bits(void)
+{
+ int array_len = get_array_length("mem_section", NULL, 0);
+ /*
+ * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
+ * newer kernels uses 46 bits.
+ */
+
+ STRUCT_SIZE_INIT(mem_section, "mem_section");
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_OLD;
+ if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+ return TRUE;
+
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_NEW;
+ if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+ return TRUE;
+
+ return FALSE;
+}
+
/*
* Do all necessary machine-specific setup here. This is called several
* times during initialization.
@@ -350,7 +373,8 @@ s390x_init(int when)
if (!machdep->hz)
machdep->hz = HZ;
machdep->section_size_bits = _SECTION_SIZE_BITS;
- machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
+ if (!set_s390x_max_physmem_bits())
+ error(FATAL, "Can't detect max_physmem_bits.");
s390x_offsets_init();
break;
10:11 a.m.
----- Original Message -----
From: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
So far s390x kernel was using 42 bits for MAX_PHYSMEM_BITS that use to
support maximum of 4TB of memory. In order to support bigger systems,
the newer s390x kernel will now use 46 bits for MAX_PHYSMEM_BITS to support
maximum of 64TB of memory.
This patch enhances crash utility to auto-detect the correct value to use
for MAX_PHYSMEM_BITS by examining the mem_section array size from the vmcore
being analyzed.
Signed-off-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
---
defs.h | 3 ++-
s390x.c | 26 +++++++++++++++++++++++++-
2 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/defs.h b/defs.h
index 381e8c2..eb992d1 100755
--- a/defs.h
+++ b/defs.h
@@ -2954,7 +2954,8 @@ struct efi_memory_desc_t {
#define TIF_SIGPENDING (2)
#define _SECTION_SIZE_BITS 28
-#define _MAX_PHYSMEM_BITS 42
+#define _MAX_PHYSMEM_BITS_OLD 42
+#define _MAX_PHYSMEM_BITS_NEW 46
#endif /* S390X */
diff --git a/s390x.c b/s390x.c
index 22e29a9..53bf272 100755
--- a/s390x.c
+++ b/s390x.c
@@ -282,6 +282,29 @@ static void s390x_process_elf_notes(void
*note_ptr, unsigned long size_note)
}
}
+static int
+set_s390x_max_physmem_bits(void)
+{
+ int array_len = get_array_length("mem_section", NULL, 0);
+ /*
+ * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
+ * newer kernels uses 46 bits.
+ */
+
+ STRUCT_SIZE_INIT(mem_section, "mem_section");
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_OLD;
+ if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+ return TRUE;
+
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_NEW;
+ if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+ return TRUE;
+
+ return FALSE;
+}
+
/*
* Do all necessary machine-specific setup here. This is called several
* times during initialization.
@@ -350,7 +373,8 @@ s390x_init(int when)
if (!machdep->hz)
machdep->hz = HZ;
machdep->section_size_bits = _SECTION_SIZE_BITS;
- machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
+ if (!set_s390x_max_physmem_bits())
+ error(FATAL, "Can't detect max_physmem_bits.");
s390x_offsets_init();
break;
This would seem to be a little extreme. If by chance CONFIG_SPARSEMEM
is not configured, or for that matter, in old pre-sparsemem kernels,
"mem_section" doesn't even exist as a symbol. So there should be an
IS_SPARSEMEM() qualifier to prevent the FATAL session-ending error.
I'm waiting for an s390x reservation as we speak, and I'll change
(and test) the patch to do something like:
if (IS_SPARSEMEM() && !set_s390x_max_physmem_bits())
error(FATAL, ...
Dave
10:22 a.m.
New subject: [PATCH] Crash-Utility: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
----- Original Message -----
----- Original Message -----
> From: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
>
> So far s390x kernel was using 42 bits for MAX_PHYSMEM_BITS that use to
> support maximum of 4TB of memory. In order to support bigger systems,
> the newer s390x kernel will now use 46 bits for MAX_PHYSMEM_BITS to support
> maximum of 64TB of memory.
>
> This patch enhances crash utility to auto-detect the correct value to use
> for MAX_PHYSMEM_BITS by examining the mem_section array size from the vmcore
> being analyzed.
>
> Signed-off-by: Mahesh Salgaonkar <mahesh(a)linux.vnet.ibm.com>
> ---
> defs.h | 3 ++-
> s390x.c | 26 +++++++++++++++++++++++++-
> 2 files changed, 27 insertions(+), 2 deletions(-)
>
> diff --git a/defs.h b/defs.h
> index 381e8c2..eb992d1 100755
> --- a/defs.h
> +++ b/defs.h
> @@ -2954,7 +2954,8 @@ struct efi_memory_desc_t {
> #define TIF_SIGPENDING (2)
>
> #define _SECTION_SIZE_BITS 28
> -#define _MAX_PHYSMEM_BITS 42
> +#define _MAX_PHYSMEM_BITS_OLD 42
> +#define _MAX_PHYSMEM_BITS_NEW 46
>
> #endif /* S390X */
>
> diff --git a/s390x.c b/s390x.c
> index 22e29a9..53bf272 100755
> --- a/s390x.c
> +++ b/s390x.c
> @@ -282,6 +282,29 @@ static void s390x_process_elf_notes(void
> *note_ptr, unsigned long size_note)
> }
> }
>
> +static int
> +set_s390x_max_physmem_bits(void)
> +{
> + int array_len = get_array_length("mem_section", NULL, 0);
> + /*
> + * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
> + * newer kernels uses 46 bits.
> + */
> +
> + STRUCT_SIZE_INIT(mem_section, "mem_section");
> + machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_OLD;
> + if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
> + || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
> + return TRUE;
> +
> + machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_NEW;
> + if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
> + || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
> + return TRUE;
> +
> + return FALSE;
> +}
> +
> /*
> * Do all necessary machine-specific setup here. This is called several
> * times during initialization.
> @@ -350,7 +373,8 @@ s390x_init(int when)
> if (!machdep->hz)
> machdep->hz = HZ;
> machdep->section_size_bits = _SECTION_SIZE_BITS;
> - machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
> + if (!set_s390x_max_physmem_bits())
> + error(FATAL, "Can't detect max_physmem_bits.");
> s390x_offsets_init();
> break;
This would seem to be a little extreme. If by chance CONFIG_SPARSEMEM
is not configured, or for that matter, in old pre-sparsemem kernels,
"mem_section" doesn't even exist as a symbol. So there should be an
IS_SPARSEMEM() qualifier to prevent the FATAL session-ending error.
I'm waiting for an s390x reservation as we speak, and I'll change
(and test) the patch to do something like:
if (IS_SPARSEMEM() && !set_s390x_max_physmem_bits())
error(FATAL, ...
Actually that won't suffice, because the POST_GDB init call is done
before vm_init(). I'll add a new POST_VM case label to the s390x_init()
switch statement, and move the set_s390x_max_physmem_bits() call there.
Dave
10:31 a.m.
New subject: [PATCH] Crash-Utility: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
----- Original Message -----
> This would seem to be a little extreme. If by chance
CONFIG_SPARSEMEM
> is not configured, or for that matter, in old pre-sparsemem kernels,
> "mem_section" doesn't even exist as a symbol. So there should be an
> IS_SPARSEMEM() qualifier to prevent the FATAL session-ending error.
>
> I'm waiting for an s390x reservation as we speak, and I'll change
> (and test) the patch to do something like:
>
> if (IS_SPARSEMEM() && !set_s390x_max_physmem_bits())
> error(FATAL, ...
Actually that won't suffice, because the POST_GDB init call is done
before vm_init(). I'll add a new POST_VM case label to the s390x_init()
switch statement, and move the set_s390x_max_physmem_bits() call
there.
... which won't work either, because vm_init() calls sparse_mem_init()
which needs the MAX_PHYSMEM_BITS to be already set.
I guess we'll have to check for the existence of the mem_section array
and preemptively/redundantly make the STRUCT_SIZE_INIT() call in your
function so that we can still do it all POST_GDB.
Dave
10:58 a.m.
New subject: [PATCH] Crash-Utility: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
----- Original Message -----
----- Original Message -----
> > This would seem to be a little extreme. If by chance CONFIG_SPARSEMEM
> > is not configured, or for that matter, in old pre-sparsemem kernels,
> > "mem_section" doesn't even exist as a symbol. So there should be
an
> > IS_SPARSEMEM() qualifier to prevent the FATAL session-ending
> > error.
> >
> > I'm waiting for an s390x reservation as we speak, and I'll change
> > (and test) the patch to do something like:
> >
> > if (IS_SPARSEMEM() &&
> > !set_s390x_max_physmem_bits())
> > error(FATAL, ...
>
> Actually that won't suffice, because the POST_GDB init call is done
> before vm_init(). I'll add a new POST_VM case label to the s390x_init()
> switch statement, and move the set_s390x_max_physmem_bits() call
> there.
... which won't work either, because vm_init() calls sparse_mem_init()
which needs the MAX_PHYSMEM_BITS to be already set.
I guess we'll have to check for the existence of the mem_section array
and preemptively/redundantly make the STRUCT_SIZE_INIT() call in your
function so that we can still do it all POST_GDB.
And complicating matters even further, your patch presumes that the
kernel has configured CONFIG_SPARSEMEM_EXTREME in conjunction with
CONFIG_SPARSEMEM. Would it be possible for an s390x to be configured
with just CONFIG_SPARSEMEM alone? If so, your patch breaks down.
Or is there another way you can determine which MAX_PHYSMEM_BITS value
is in use?
Dave
11:12 a.m.
New subject: [PATCH] Crash-Utility: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
----- Original Message -----
And complicating matters even further, your patch presumes that the
kernel has configured CONFIG_SPARSEMEM_EXTREME in conjunction with
CONFIG_SPARSEMEM. Would it be possible for an s390x to be configured
with just CONFIG_SPARSEMEM alone? If so, your patch breaks down.
Or is there another way you can determine which MAX_PHYSMEM_BITS value
is in use?
Dave
Using your scheme, this is the best I can come up with (untested):
--- s390x.c 10 Nov 2011 14:37:15 -0000 1.57
+++ s390x.c 21 Dec 2011 17:07:20 -0000
@@ -282,6 +282,43 @@
}
}
+static int
+set_s390x_max_physmem_bits(void)
+{
+ int array_len, dimension;
+
+ if (!kernel_symbol_exists("mem_section"))
+ return TRUE;
+
+ if (!(array_len = get_array_length("mem_section", &dimension, 0))
+ return FALSE;
+
+ /*
+ * If not CONFIG_SPARSEMEM_EXTREME, presume the older 42.
+ */
+ if (dimension) {
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_OLD;
+ return TRUE;
+ }
+
+ /*
+ * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
+ * newer kernels uses 46 bits.
+ */
+ STRUCT_SIZE_INIT(mem_section, "mem_section");
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_OLD;
+ if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+ return TRUE;
+
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_NEW;
+ if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+ return TRUE;
+
+ return FALSE;
+}
+
/*
* Do all necessary machine-specific setup here. This is called several
* times during initialization.
@@ -350,7 +387,8 @@
if (!machdep->hz)
machdep->hz = HZ;
machdep->section_size_bits = _SECTION_SIZE_BITS;
- machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
+ if (!set_s390x_max_physmem_bits())
+ error(FATAL, "cannot determine MAX_PHYSMEM_BITS");
s390x_offsets_init();
break;
3:26 a.m.
New subject: [PATCH]Crash-Utility: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
On 2011-12-21 12:12:54 Wed, Dave Anderson wrote:
----- Original Message -----
>
> And complicating matters even further, your patch presumes that the
> kernel has configured CONFIG_SPARSEMEM_EXTREME in conjunction with
> CONFIG_SPARSEMEM. Would it be possible for an s390x to be configured
> with just CONFIG_SPARSEMEM alone? If so, your patch breaks down.
>
> Or is there another way you can determine which MAX_PHYSMEM_BITS value
> is in use?
>
> Dave
>
Using your scheme, this is the best I can come up with (untested):
--- s390x.c 10 Nov 2011 14:37:15 -0000 1.57
+++ s390x.c 21 Dec 2011 17:07:20 -0000
@@ -282,6 +282,43 @@
}
}
+static int
+set_s390x_max_physmem_bits(void)
+{
+ int array_len, dimension;
+
+ if (!kernel_symbol_exists("mem_section"))
+ return TRUE;
+
+ if (!(array_len = get_array_length("mem_section", &dimension, 0))
+ return FALSE;
+
Agree, Makes sense.
+ /*
+ * If not CONFIG_SPARSEMEM_EXTREME, presume the older 42.
+ */
+ if (dimension) {
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_OLD;
+ return TRUE;
+ }
Even with max_physmem_bits = 46, it may be possible that newer kernel can be
built with CONFIG_SPARSEMEM and !CONFIG_SPARSEMEM_EXTREME. In which case
dimension can still hold +ve value and we may end up seletecting wrong
value for physmem_bits.
+
+ /*
+ * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
+ * newer kernels uses 46 bits.
+ */
+ STRUCT_SIZE_INIT(mem_section, "mem_section");
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_OLD;
+ if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+ return TRUE;
+
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_NEW;
+ if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+ return TRUE;
+
+ return FALSE;
+}
+
The above code does compare array_len for both the conditions
CONFIG_SPARSEMEM_EXTREME and !CONFIG_SPARSEMEM_EXTREME for old/new
max_physmem_bits. However, with use of dimension value the above
logic can be more simpler like this:
diff --git a/s390x.c b/s390x.c
index 22e29a9..5b6a38e 100755
--- a/s390x.c
+++ b/s390x.c
@@ -282,6 +282,53 @@ static void s390x_process_elf_notes(void *note_ptr, unsigned long
size_note)
}
}
+static int
+set_s390x_max_physmem_bits(void)
+{
+ int array_len, dimension;
+
+ if (!kernel_symbol_exists("mem_section"))
+ return TRUE;
+
+ if (!(array_len = get_array_length("mem_section", &dimension, 0)))
+ return FALSE;
+
+ /*
+ * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
+ * newer kernels uses 46 bits.
+ */
+
+ STRUCT_SIZE_INIT(mem_section, "mem_section");
+
+ /*
+ * !CONFIG_SPARSEMEM_EXTREME
+ */
+ if (dimension) {
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_OLD;
+ if (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT()))
+ return TRUE;
+
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_NEW;
+ if (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT()))
+ return TRUE;
+
+ return FALSE;
+ }
+
+ /*
+ * CONFIG_SPARSEMEM_EXTREME
+ */
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_OLD;
+ if (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ return TRUE;
+
+ machdep->max_physmem_bits = _MAX_PHYSMEM_BITS_NEW;
+ if (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ return TRUE;
+
+ return FALSE;
+}
+
/*
* Do all necessary machine-specific setup here. This is called several
* times during initialization.
What do you think?
Thanks,
-Mahesh.
--
Mahesh J Salgaonkar
7:26 a.m.
New subject: [PATCH] crash: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed
Hello Dave and Mahesh,
We also tried to solve the problem and came up with an alternative solution.
The function s390x_max_physmem_bits() solves the following equation:
array_len == NR_MEM_SECTIONS / SECTIONS_PER_ROOT
2^(MAX_PYSMEM_BITS - SECTION_SIZE_BITS)
---------------------------------------
== PAGE_SIZE
-------------------------
sizeof(struct mem_section)
This leads to the following:
MAX_PYSMEM_BITS == SECTION_SIZE_BITS + log2(array_len) + log2(PAGE_SIZE)
- log2(sizeof(struct mem_section));
I tested the patch with 42 and 46 bits and for both it seems to work.
I will leave now for vacation and will return January the 9th 2012.
I leave it to you which solution to take.
Merry Christmas!
Michael
PS: I think this patch also fixes a bug in verify_ptn()...
BTOP vs. PTOB :-)
---
kernel.c | 2 +-
memory.c | 2 +-
s390x.c | 17 ++++++++++++++++-
3 files changed, 18 insertions(+), 3 deletions(-)
--- a/kernel.c
+++ b/kernel.c
@@ -275,7 +275,7 @@ kernel_init()
MEMBER_OFFSET_INIT(prio_array_nr_active, "prio_array",
"nr_active");
STRUCT_SIZE_INIT(runqueue, rqstruct);
STRUCT_SIZE_INIT(prio_array, "prio_array");
-
+ STRUCT_SIZE_INIT(mem_section, "mem_section");
MEMBER_OFFSET_INIT(rq_cfs, "rq", "cfs");
/*
--- a/memory.c
+++ b/memory.c
@@ -13601,7 +13601,7 @@ verify_pfn(ulong pfn)
for (i = machdep->max_physmem_bits; i < machdep->bits; i++)
mask |= ((physaddr_t)1 << i);
- if (mask & BTOP(pfn))
+ if (mask & PTOB(pfn))
return FALSE;
return TRUE;
--- a/s390x.c
+++ b/s390x.c
@@ -17,6 +17,7 @@
*/
#ifdef S390X
#include <elf.h>
+#include <math.h>
#include "defs.h"
#include "netdump.h"
@@ -283,6 +284,19 @@ static void s390x_process_elf_notes(void
}
/*
+ * The older s390x kernels use _MAX_PHYSMEM_BITS as 42 and the
+ * newer kernels use 46 bits. This function calculates the bits
+ * via a generic function.
+ */
+static int s390x_max_physmem_bits(void)
+{
+ unsigned long array_len = get_array_length("mem_section", NULL, 0);
+
+ return _SECTION_SIZE_BITS + log2(array_len) + 12 /* log2(PAGE_SIZE) */
+ - log2(SIZE(mem_section));
+}
+
+/*
* Do all necessary machine-specific setup here. This is called several
* times during initialization.
*/
@@ -350,13 +364,14 @@ s390x_init(int when)
if (!machdep->hz)
machdep->hz = HZ;
machdep->section_size_bits = _SECTION_SIZE_BITS;
- machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
+ machdep->max_physmem_bits = s390x_max_physmem_bits();
s390x_offsets_init();
break;
case POST_INIT:
break;
}
+ fprintf(stderr, "XXX %d\n", machdep->max_physmem_bits);
}
/*
7:47 a.m.
New subject: [PATCH] crash: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed
----- Original Message -----
Hello Dave and Mahesh,
We also tried to solve the problem and came up with an alternative
solution.
The function s390x_max_physmem_bits() solves the following equation:
array_len == NR_MEM_SECTIONS / SECTIONS_PER_ROOT
2^(MAX_PYSMEM_BITS - SECTION_SIZE_BITS)
---------------------------------------
== PAGE_SIZE
-------------------------
sizeof(struct mem_section)
This leads to the following:
MAX_PYSMEM_BITS == SECTION_SIZE_BITS + log2(array_len) +
log2(PAGE_SIZE)
- log2(sizeof(struct mem_section));
I tested the patch with 42 and 46 bits and for both it seems to work.
I will leave now for vacation and will return January the 9th 2012.
I leave it to you which solution to take.
No -- I leave to you guys to decide. I appreciate the simplicity of
your solution, but Mahesh's patch is easier to understand.
So please decide before you go home -- I was hoping to get a release
out today!
Merry Christmas!
Michael
PS: I think this patch also fixes a bug in verify_ptn()...
BTOP vs. PTOB :-)
Hey, you're right!
Dave
---
kernel.c | 2 +-
memory.c | 2 +-
s390x.c | 17 ++++++++++++++++-
3 files changed, 18 insertions(+), 3 deletions(-)
--- a/kernel.c
+++ b/kernel.c
@@ -275,7 +275,7 @@ kernel_init()
MEMBER_OFFSET_INIT(prio_array_nr_active, "prio_array",
"nr_active");
STRUCT_SIZE_INIT(runqueue, rqstruct);
STRUCT_SIZE_INIT(prio_array, "prio_array");
-
+ STRUCT_SIZE_INIT(mem_section, "mem_section");
MEMBER_OFFSET_INIT(rq_cfs, "rq", "cfs");
/*
--- a/memory.c
+++ b/memory.c
@@ -13601,7 +13601,7 @@ verify_pfn(ulong pfn)
for (i = machdep->max_physmem_bits; i < machdep->bits; i++)
mask |= ((physaddr_t)1 << i);
- if (mask & BTOP(pfn))
+ if (mask & PTOB(pfn))
return FALSE;
return TRUE;
--- a/s390x.c
+++ b/s390x.c
@@ -17,6 +17,7 @@
*/
#ifdef S390X
#include <elf.h>
+#include <math.h>
#include "defs.h"
#include "netdump.h"
@@ -283,6 +284,19 @@ static void s390x_process_elf_notes(void
}
/*
+ * The older s390x kernels use _MAX_PHYSMEM_BITS as 42 and the
+ * newer kernels use 46 bits. This function calculates the bits
+ * via a generic function.
+ */
+static int s390x_max_physmem_bits(void)
+{
+ unsigned long array_len = get_array_length("mem_section", NULL, 0);
+
+ return _SECTION_SIZE_BITS + log2(array_len) + 12 /* log2(PAGE_SIZE)
*/
+ - log2(SIZE(mem_section));
+}
+
+/*
* Do all necessary machine-specific setup here. This is called
several
* times during initialization.
*/
@@ -350,13 +364,14 @@ s390x_init(int when)
if (!machdep->hz)
machdep->hz = HZ;
machdep->section_size_bits = _SECTION_SIZE_BITS;
- machdep->max_physmem_bits = _MAX_PHYSMEM_BITS;
+ machdep->max_physmem_bits = s390x_max_physmem_bits();
s390x_offsets_init();
break;
case POST_INIT:
break;
}
+ fprintf(stderr, "XXX %d\n", machdep->max_physmem_bits);
}
/*
8:15 a.m.
New subject: [PATCH] crash: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed
Hi Dave,
On Thu, 2011-12-22 at 08:47 -0500, Dave Anderson wrote:
----- Original Message -----
> Hello Dave and Mahesh,
>
> We also tried to solve the problem and came up with an alternative
> solution.
>
> The function s390x_max_physmem_bits() solves the following equation:
>
> array_len == NR_MEM_SECTIONS / SECTIONS_PER_ROOT
>
> 2^(MAX_PYSMEM_BITS - SECTION_SIZE_BITS)
> ---------------------------------------
> == PAGE_SIZE
> -------------------------
> sizeof(struct mem_section)
>
> This leads to the following:
>
> MAX_PYSMEM_BITS == SECTION_SIZE_BITS + log2(array_len) +
> log2(PAGE_SIZE)
> - log2(sizeof(struct mem_section));
>
> I tested the patch with 42 and 46 bits and for both it seems to work.
> I will leave now for vacation and will return January the 9th 2012.
>
> I leave it to you which solution to take.
No -- I leave to you guys to decide. I appreciate the simplicity of
your solution, but Mahesh's patch is easier to understand.
So please decide before you go home -- I was hoping to get a release
out today!
Unfortunately Mahesh is currently not online. We still have some time
because Martin's kernel patch that introduces the change will go into
Linux version 3.3.
So perhaps you make your crash release without this patch.
Michael
8:19 a.m.
New subject: [PATCH] crash: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed
----- Original Message -----
Unfortunately Mahesh is currently not online. We still have some time
because Martin's kernel patch that introduces the change will go into
Linux version 3.3.
So perhaps you make your crash release without this patch.
Michael
Tell you what -- I'm going to make a hybrid patch, using Mahesh's
more understandable-yet-longer function, but with your verify_pfn()
and STRUCT_SIZE_INIT("mem_section") movement, along with a default
setting of 42 and a non-fatal WARNING message if things fail.
I'll verify it on RHEL5 and RHEL6.
If you want to change it later, that will be fine, too.
Thanks,
Dave
8:33 a.m.
New subject: [PATCH] crash: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed
Hi Dave,
On Thu, 2011-12-22 at 09:19 -0500, Dave Anderson wrote:
----- Original Message -----
>
> Unfortunately Mahesh is currently not online. We still have some time
> because Martin's kernel patch that introduces the change will go into
> Linux version 3.3.
>
> So perhaps you make your crash release without this patch.
>
> Michael
Tell you what -- I'm going to make a hybrid patch, using Mahesh's
more understandable-yet-longer function, but with your verify_pfn()
and STRUCT_SIZE_INIT("mem_section") movement, along with a default
setting of 42 and a non-fatal WARNING message if things fail.
I'll verify it on RHEL5 and RHEL6.
If you want to change it later, that will be fine, too.
Ok, I will have a look at your next crash release in the new year.
Thanks!
Michael
8:53 a.m.
New subject: [PATCH] crash: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed
----- Original Message -----
Hi Dave,
On Thu, 2011-12-22 at 09:19 -0500, Dave Anderson wrote:
>
> ----- Original Message -----
> >
> > Unfortunately Mahesh is currently not online. We still have some time
> > because Martin's kernel patch that introduces the change will go into
> > Linux version 3.3.
> >
> > So perhaps you make your crash release without this patch.
> >
> > Michael
>
> Tell you what -- I'm going to make a hybrid patch, using Mahesh's
> more understandable-yet-longer function, but with your verify_pfn()
> and STRUCT_SIZE_INIT("mem_section") movement, along with a default
> setting of 42 and a non-fatal WARNING message if things fail.
> I'll verify it on RHEL5 and RHEL6.
>
> If you want to change it later, that will be fine, too.
Ok, I will have a look at your next crash release in the new year.
Thanks!
Michael
I've attached what I'm going with -- freshly tested on RHEL5 and RHEL6.
And interestingly enough -- even RHEL5 is still FLATMEM.
Thanks guys,
Dave
3:06 a.m.
New subject: [PATCH] Crash-Utility: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
On 12/21/2011 10:28 PM, Dave Anderson wrote:
And complicating matters even further, your patch presumes that the
kernel has configured CONFIG_SPARSEMEM_EXTREME in conjunction with
CONFIG_SPARSEMEM. Would it be possible for an s390x to be configured
with just CONFIG_SPARSEMEM alone?
Not sure. I have never tried building s390x kernel configured with just
CONFIG_SPARSEMEM alone.
If so, your patch breaks down.
Or is there another way you can determine which MAX_PHYSMEM_BITS value
is in use?
This value is a #define constant and I dont see any kernel symbol
holding this value which could have been easy way to determine this value.
Thanks,
-Mahesh.
3:28 a.m.
New subject: [PATCH] Crash-Utility: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
Hello Mahesh, Dave,
I am no expert on memory management, but...
Mahesh Jagannath Salgaonkar <mahesh(a)linux.vnet.ibm.com> wrote on 12/22/2011
10:06:43:
> And complicating matters even further, your patch presumes that
the
> kernel has configured CONFIG_SPARSEMEM_EXTREME in conjunction with
> CONFIG_SPARSEMEM. Would it be possible for an s390x to be configured
> with just CONFIG_SPARSEMEM alone?
Not sure. I have never tried building s390x kernel configured with just
CONFIG_SPARSEMEM alone.
On s390x CONFIG_SPARSEMEM, CONFIG_SPARSEMEM_EXTREME, and SPARSEMEM_VMEMMAP
is always enabled.
Michael
8:02 a.m.
New subject: [PATCH] Crash-Utility: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
----- Original Message -----
Hello Mahesh, Dave,
I am no expert on memory management, but...
Mahesh Jagannath Salgaonkar <mahesh(a)linux.vnet.ibm.com> wrote on
12/22/2011
10:06:43:
> > And complicating matters even further, your patch presumes that the
> > kernel has configured CONFIG_SPARSEMEM_EXTREME in conjunction with
> > CONFIG_SPARSEMEM. Would it be possible for an s390x to be configured
> > with just CONFIG_SPARSEMEM alone?
>
> Not sure. I have never tried building s390x kernel configured with just
> CONFIG_SPARSEMEM alone.
On s390x CONFIG_SPARSEMEM, CONFIG_SPARSEMEM_EXTREME, and SPARSEMEM_VMEMMAP
is always enabled.
But old kernels like RHEL4 don't have SPARSEMEM.
Dave
4573
days inactive
4574
days old
devel@lists.crash-utility.osci.io
15 comments
5 participants
participants (5)
-
Dave Anderson -
Mahesh J Salgaonkar -
Mahesh Jagannath Salgaonkar
-
Michael Holzheu -
Michael Holzheu