From: tachibana@mxm.nes.nec.co.jp
To: Mahesh J Salgaonkar <mahesh@linux.vnet.ibm.com>
Cc: Tachibana-san <tachibana@mxm.nes.nec.co.jp>,
Michael Holzheu <holzheu@linux.vnet.ibm.com>,
Kexec-ml <kexec@lists.infradead.org>,
Ananth Narayan <ananth@in.ibm.com>,
Reinhard <BUENDGEN@de.ibm.com>
Subject: Re: [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSused in vmcore being analyzed.
Date: Wed, 21 Dec 2011 15:11:41 +0900 [thread overview]
Message-ID: <20111221151141tachibana@mail.jp.nec.com> (raw)
In-Reply-To: <20111220101459.26622.49407.stgit@mars.in.ibm.com>
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
next prev parent reply other threads:[~2011-12-21 6:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2011-12-21 10:08 ` [PATCH] makedumpfile: s390x: Auto-detect the correct MAX_PHYSMEM_BITSused " 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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111221151141tachibana@mail.jp.nec.com \
--to=tachibana@mxm.nes.nec.co.jp \
--cc=BUENDGEN@de.ibm.com \
--cc=ananth@in.ibm.com \
--cc=holzheu@linux.vnet.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=mahesh@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.