* [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
@ 2011-12-20 10:36 Mahesh J Salgaonkar
2011-12-20 13:21 ` Michael Holzheu
2011-12-21 6:11 ` [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSused " tachibana
0 siblings, 2 replies; 6+ messages in thread
From: Mahesh J Salgaonkar @ 2011-12-20 10:36 UTC (permalink / raw)
To: Tachibana-san, Kexec-ml; +Cc: Michael Holzheu, Ananth Narayan, Reinhard
Hi Tachibana,
As part of the s390 patch to add support for > 4TB system memory (present in
linux-next tree), the newer s390 kernel will bump the MAX_PHYSMEM_BITS from
42 to 46. Once that patch makes into umpstream kernel, this change will need
to go into makedumpfile. For now, I am posting this patch for a review.
Reference: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=8980036860565a6d2a4f95bb097927e832fa3d1a
Thanks,
-Mahesh.
From: Mahesh Salgaonkar <mahesh@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 auto-detects 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@linux.vnet.ibm.com>
---
arch/s390x.c | 27 ++++++++++++++++++++++++++-
makedumpfile.h | 3 ++-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/s390x.c b/arch/s390x.c
index 9237eaa..c73220a 100644
--- a/arch/s390x.c
+++ b/arch/s390x.c
@@ -60,6 +60,28 @@
#define pte_offset(x) (pte_index(x) * sizeof(unsigned long))
int
+set_s390x_max_physmem_bits(void)
+{
+ long array_len = ARRAY_LENGTH(mem_section);
+ /*
+ * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
+ * newer kernels uses 46 bits.
+ */
+
+ info->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;
+
+ info->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;
+}
+
+int
get_machdep_info_s390x(void)
{
unsigned long vmalloc_start;
@@ -70,7 +92,10 @@ get_machdep_info_s390x(void)
flag_ignore_r_char = 1;
info->section_size_bits = _SECTION_SIZE_BITS;
- info->max_physmem_bits = _MAX_PHYSMEM_BITS;
+ if (!set_s390x_max_physmem_bits()) {
+ ERRMSG("Can't detect max_physmem_bits.\n");
+ return FALSE;
+ }
info->page_offset = __PAGE_OFFSET;
if (SYMBOL(_stext) == NOT_FOUND_SYMBOL) {
diff --git a/makedumpfile.h b/makedumpfile.h
index b3de521..a95d132 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -531,7 +531,8 @@ do { \
#define KERNELBASE (0)
#define KVBASE KERNELBASE
#define _SECTION_SIZE_BITS (28)
-#define _MAX_PHYSMEM_BITS (42)
+#define _MAX_PHYSMEM_BITS_OLD (42)
+#define _MAX_PHYSMEM_BITS_NEW (46)
/* Bits in the segment/region table address-space-control-element */
#define _ASCE_TYPE_MASK 0x0c
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed.
2011-12-20 10:36 [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed Mahesh J Salgaonkar
@ 2011-12-20 13:21 ` Michael Holzheu
2011-12-21 6:11 ` [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSused " tachibana
1 sibling, 0 replies; 6+ messages in thread
From: Michael Holzheu @ 2011-12-20 13:21 UTC (permalink / raw)
To: Mahesh J Salgaonkar; +Cc: Tachibana-san, Kexec-ml, Ananth Narayan, Reinhard
Hello,
The s390 kernel patch is queued for the next merge window therefore will
go upstream. My recommendation is to include the makedumpfile patch
already now if it passes the review.
Best Regards
Michael
On Tue, 2011-12-20 at 16:06 +0530, Mahesh J Salgaonkar wrote:
> Hi Tachibana,
>
> As part of the s390 patch to add support for > 4TB system memory (present in
> linux-next tree), the newer s390 kernel will bump the MAX_PHYSMEM_BITS from
> 42 to 46. Once that patch makes into umpstream kernel, this change will need
> to go into makedumpfile. For now, I am posting this patch for a review.
>
> Reference: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=8980036860565a6d2a4f95bb097927e832fa3d1a
>
> Thanks,
> -Mahesh.
>
>
> From: Mahesh Salgaonkar <mahesh@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 auto-detects 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@linux.vnet.ibm.com>
> ---
> arch/s390x.c | 27 ++++++++++++++++++++++++++-
> makedumpfile.h | 3 ++-
> 2 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/arch/s390x.c b/arch/s390x.c
> index 9237eaa..c73220a 100644
> --- a/arch/s390x.c
> +++ b/arch/s390x.c
> @@ -60,6 +60,28 @@
> #define pte_offset(x) (pte_index(x) * sizeof(unsigned long))
>
> int
> +set_s390x_max_physmem_bits(void)
> +{
> + long array_len = ARRAY_LENGTH(mem_section);
> + /*
> + * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
> + * newer kernels uses 46 bits.
> + */
> +
> + info->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;
> +
> + info->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;
> +}
> +
> +int
> get_machdep_info_s390x(void)
> {
> unsigned long vmalloc_start;
> @@ -70,7 +92,10 @@ get_machdep_info_s390x(void)
> flag_ignore_r_char = 1;
>
> info->section_size_bits = _SECTION_SIZE_BITS;
> - info->max_physmem_bits = _MAX_PHYSMEM_BITS;
> + if (!set_s390x_max_physmem_bits()) {
> + ERRMSG("Can't detect max_physmem_bits.\n");
> + return FALSE;
> + }
> info->page_offset = __PAGE_OFFSET;
>
> if (SYMBOL(_stext) == NOT_FOUND_SYMBOL) {
> diff --git a/makedumpfile.h b/makedumpfile.h
> index b3de521..a95d132 100644
> --- a/makedumpfile.h
> +++ b/makedumpfile.h
> @@ -531,7 +531,8 @@ do { \
> #define KERNELBASE (0)
> #define KVBASE KERNELBASE
> #define _SECTION_SIZE_BITS (28)
> -#define _MAX_PHYSMEM_BITS (42)
> +#define _MAX_PHYSMEM_BITS_OLD (42)
> +#define _MAX_PHYSMEM_BITS_NEW (46)
>
> /* Bits in the segment/region table address-space-control-element */
> #define _ASCE_TYPE_MASK 0x0c
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSused in vmcore being analyzed.
2011-12-20 10:36 [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed Mahesh J Salgaonkar
2011-12-20 13:21 ` Michael Holzheu
@ 2011-12-21 6:11 ` tachibana
2011-12-21 10:08 ` Mahesh Jagannath Salgaonkar
1 sibling, 1 reply; 6+ messages in thread
From: tachibana @ 2011-12-21 6:11 UTC (permalink / raw)
To: Mahesh J Salgaonkar
Cc: Tachibana-san, Michael Holzheu, Kexec-ml, Ananth Narayan, Reinhard
Hi Mahesh,
Thank you for the patch.
I will review it.
However I have never dumped 1 terabyte or more data using makedumpfile.
Has anyone ever dumped it successfully?
Thanks.
tachibana
On 2011/12/20 16:06:01 +0530, Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> Hi Tachibana,
>
> As part of the s390 patch to add support for > 4TB system memory (present in
> linux-next tree), the newer s390 kernel will bump the MAX_PHYSMEM_BITS from
> 42 to 46. Once that patch makes into umpstream kernel, this change will need
> to go into makedumpfile. For now, I am posting this patch for a review.
>
> Reference: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=8980036860565a6d2a4f95bb097927e832
fa3d1a
>
> Thanks,
> -Mahesh.
>
>
> From: Mahesh Salgaonkar <mahesh@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 auto-detects 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@linux.vnet.ibm.com>
> ---
> arch/s390x.c | 27 ++++++++++++++++++++++++++-
> makedumpfile.h | 3 ++-
> 2 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/arch/s390x.c b/arch/s390x.c
> index 9237eaa..c73220a 100644
> --- a/arch/s390x.c
> +++ b/arch/s390x.c
> @@ -60,6 +60,28 @@
> #define pte_offset(x) (pte_index(x) * sizeof(unsigned long))
>
> int
> +set_s390x_max_physmem_bits(void)
> +{
> + long array_len = ARRAY_LENGTH(mem_section);
> + /*
> + * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
> + * newer kernels uses 46 bits.
> + */
> +
> + info->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;
> +
> + info->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;
> +}
> +
> +int
> get_machdep_info_s390x(void)
> {
> unsigned long vmalloc_start;
> @@ -70,7 +92,10 @@ get_machdep_info_s390x(void)
> flag_ignore_r_char = 1;
>
> info->section_size_bits = _SECTION_SIZE_BITS;
> - info->max_physmem_bits = _MAX_PHYSMEM_BITS;
> + if (!set_s390x_max_physmem_bits()) {
> + ERRMSG("Can't detect max_physmem_bits.\n");
> + return FALSE;
> + }
> info->page_offset = __PAGE_OFFSET;
>
> if (SYMBOL(_stext) == NOT_FOUND_SYMBOL) {
> diff --git a/makedumpfile.h b/makedumpfile.h
> index b3de521..a95d132 100644
> --- a/makedumpfile.h
> +++ b/makedumpfile.h
> @@ -531,7 +531,8 @@ do { \
> #define KERNELBASE (0)
> #define KVBASE KERNELBASE
> #define _SECTION_SIZE_BITS (28)
> -#define _MAX_PHYSMEM_BITS (42)
> +#define _MAX_PHYSMEM_BITS_OLD (42)
> +#define _MAX_PHYSMEM_BITS_NEW (46)
>
> /* Bits in the segment/region table address-space-control-element */
> #define _ASCE_TYPE_MASK 0x0c
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSused in vmcore being analyzed.
2011-12-21 6:11 ` [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSused " tachibana
@ 2011-12-21 10:08 ` Mahesh Jagannath Salgaonkar
2011-12-21 12:48 ` [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSusedin " tachibana
0 siblings, 1 reply; 6+ messages in thread
From: Mahesh Jagannath Salgaonkar @ 2011-12-21 10:08 UTC (permalink / raw)
To: tachibana; +Cc: Michael Holzheu, Kexec-ml, Ananth Narayan, Reinhard
On 12/21/2011 11:41 AM, tachibana@mxm.nes.nec.co.jp wrote:
> Hi Mahesh,
>
> Thank you for the patch.
> I will review it.
> However I have never dumped 1 terabyte or more data using makedumpfile.
> Has anyone ever dumped it successfully?
>
I have seen makedumpfile successfully compressing vmcore generated on
system with 1TB memory.
Thanks,
-Mahesh.
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSusedin vmcore being analyzed.
2011-12-21 10:08 ` Mahesh Jagannath Salgaonkar
@ 2011-12-21 12:48 ` tachibana
2012-01-17 4:40 ` Atsushi Kumagai
0 siblings, 1 reply; 6+ messages in thread
From: tachibana @ 2011-12-21 12:48 UTC (permalink / raw)
To: Mahesh Jagannath Salgaonkar
Cc: tachibana, Michael Holzheu, Kexec-ml, Ananth Narayan, Reinhard
Hi Mahesh,
On 2011/12/21 15:38:25 +0530, Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> On 12/21/2011 11:41 AM, tachibana@mxm.nes.nec.co.jp wrote:
> > Hi Mahesh,
> >
> > Thank you for the patch.
> > I will review it.
> > However I have never dumped 1 terabyte or more data using makedumpfile.
> > Has anyone ever dumped it successfully?
> >
>
> I have seen makedumpfile successfully compressing vmcore generated on
> system with 1TB memory.
Thank you for your information.
Thanks.
tachibana
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSusedin vmcore being analyzed.
2011-12-21 12:48 ` [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSusedin " tachibana
@ 2012-01-17 4:40 ` Atsushi Kumagai
0 siblings, 0 replies; 6+ messages in thread
From: Atsushi Kumagai @ 2012-01-17 4:40 UTC (permalink / raw)
To: mahesh; +Cc: tachibana, holzheu, kexec, ananth, BUENDGEN
Hi Mahesh,
On Wed, 21 Dec 2011 21:48:09 +0900
tachibana@mxm.nes.nec.co.jp wrote:
> Hi Mahesh,
>
> On 2011/12/21 15:38:25 +0530, Mahesh Jagannath Salgaonkar <mahesh@linux.vnet.ibm.com> wrote:
> > On 12/21/2011 11:41 AM, tachibana@mxm.nes.nec.co.jp wrote:
> > > Hi Mahesh,
> > >
> > > Thank you for the patch.
> > > I will review it.
> > > However I have never dumped 1 terabyte or more data using makedumpfile.
> > > Has anyone ever dumped it successfully?
> > >
> >
> > I have seen makedumpfile successfully compressing vmcore generated on
> > system with 1TB memory.
>
> Thank you for your information.
I will merge your patch with renaming macros as:
_MAX_PHYSMEM_BITS_OLD -> _MAX_PHYSMEM_BITS_ORIG
_MAX_PHYSMEM_BITS_NEW -> _MAX_PHYSMEM_BITS_3_3
So, attached patch queued for makedumpfile-1.4.2.
Thanks
Atsushi Kumagai
From: Mahesh Salgaonkar <mahesh@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 auto-detects 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@linux.vnet.ibm.com>
Rename _MAX_PHYSMEM_BITS_OLD to _MAX_PHYSMEM_BITS_ORIG
and _MAX_PHYSMEM_BITS_NEW to _MAX_PHYSMEM_BITS_3_3.
Signed-off-by: Atsushi Kumagai <kumagai-atsushi@mxc.nes.nec.co.jp>
---
arch/s390x.c | 27 ++++++++++++++++++++++++++-
makedumpfile.h | 3 ++-
2 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/arch/s390x.c b/arch/s390x.c
index 9237eaa..02b9e63 100644
--- a/arch/s390x.c
+++ b/arch/s390x.c
@@ -60,6 +60,28 @@
#define pte_offset(x) (pte_index(x) * sizeof(unsigned long))
int
+set_s390x_max_physmem_bits(void)
+{
+ long array_len = ARRAY_LENGTH(mem_section);
+ /*
+ * The older s390x kernels uses _MAX_PHYSMEM_BITS as 42 and the
+ * newer kernels uses 46 bits.
+ */
+
+ info->max_physmem_bits = _MAX_PHYSMEM_BITS_ORIG ;
+ if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+ return TRUE;
+
+ info->max_physmem_bits = _MAX_PHYSMEM_BITS_3_3;
+ if ((array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT_EXTREME()))
+ || (array_len == (NR_MEM_SECTIONS() / _SECTIONS_PER_ROOT())))
+ return TRUE;
+
+ return FALSE;
+}
+
+int
get_machdep_info_s390x(void)
{
unsigned long vmalloc_start;
@@ -70,7 +92,10 @@ get_machdep_info_s390x(void)
flag_ignore_r_char = 1;
info->section_size_bits = _SECTION_SIZE_BITS;
- info->max_physmem_bits = _MAX_PHYSMEM_BITS;
+ if (!set_s390x_max_physmem_bits()) {
+ ERRMSG("Can't detect max_physmem_bits.\n");
+ return FALSE;
+ }
info->page_offset = __PAGE_OFFSET;
if (SYMBOL(_stext) == NOT_FOUND_SYMBOL) {
diff --git a/makedumpfile.h b/makedumpfile.h
index 4b4a58b..ebb8929 100644
--- a/makedumpfile.h
+++ b/makedumpfile.h
@@ -535,7 +535,8 @@ do { \
#define KERNELBASE (0)
#define KVBASE KERNELBASE
#define _SECTION_SIZE_BITS (28)
-#define _MAX_PHYSMEM_BITS (42)
+#define _MAX_PHYSMEM_BITS_ORIG (42)
+#define _MAX_PHYSMEM_BITS_3_3 (46)
/* Bits in the segment/region table address-space-control-element */
#define _ASCE_TYPE_MASK 0x0c
--
1.6.5.3
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-17 5:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-20 10:36 [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITS used in vmcore being analyzed Mahesh J Salgaonkar
2011-12-20 13:21 ` Michael Holzheu
2011-12-21 6:11 ` [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSused " tachibana
2011-12-21 10:08 ` Mahesh Jagannath Salgaonkar
2011-12-21 12:48 ` [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSusedin " tachibana
2012-01-17 4:40 ` Atsushi Kumagai
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.