From: Dave Anderson <anderson@redhat.com>
To: kexec@lists.infradead.org
Cc: Dave Young <dyoung@redhat.com>, CAI Qian <caiqian@redhat.com>
Subject: Re: makedumpfile bug with ppc64 CONFIG_SPARSEMEM_EXTREME
Date: Thu, 10 Jan 2013 16:09:23 -0500 (EST) [thread overview]
Message-ID: <1268295784.3657868.1357852163361.JavaMail.root@redhat.com> (raw)
In-Reply-To: <1906730150.3445569.1357844143086.JavaMail.root@redhat.com>
----- Original Message -----
>
> Our QA group recently ran into a makedumpfile problem while
> testing kdump/makedumpfile w/upstream 3.7.1 kernels, which
> had to do with the filtering of pages on a 12GB ppc64 system.
>
... [ cut ] ...
>
> I haven't checked why the original math fails in the case of the
> ppc64 kernel, while it does not fail in a CONFIG_SPARSEMEM_EXTREME
> x86_64 kernel, for example. (page size maybe?) But obviously the
> simpler dimemsion-check is a better way to do it.
>
> Of course, within the current constraints of makedumpfile, it's not
> that easy. Ideally the kernel could pass the configuration in
> the vmcoreinfo with a VMCOREINFO_CONFIG(name). But anyway, I'll leave
> that up to you.
>
> Thanks,
> Dave
It's presumably being seen in 3.7.1 because of this commit:
$ git log -p arch/powerpc/include/asm/sparsemem.h
commit 048ee0993ec8360abb0b51bdf8f8721e9ed62ec4
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date: Mon Sep 10 02:52:55 2012 +0000
powerpc/mm: Add 64TB support
Increase max addressable range to 64TB. This is not tested on
real hardware yet.
Reviewed-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
diff --git a/arch/powerpc/include/asm/sparsemem.h b/arch/powerpc/include/asm/sparsemem.h
index 0c5fa31..f6fc0ee 100644
--- a/arch/powerpc/include/asm/sparsemem.h
+++ b/arch/powerpc/include/asm/sparsemem.h
@@ -10,8 +10,8 @@
*/
#define SECTION_SIZE_BITS 24
-#define MAX_PHYSADDR_BITS 44
-#define MAX_PHYSMEM_BITS 44
+#define MAX_PHYSADDR_BITS 46
+#define MAX_PHYSMEM_BITS 46
#endif /* CONFIG_SPARSEMEM */
$ git describe --contains 048ee0993ec8360abb0b51bdf8f8721e9ed62ec4
v3.7-rc1~108^2~32
$
Dave
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-01-10 21:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1276992529.3443656.1357843852315.JavaMail.root@redhat.com>
2013-01-10 18:55 ` makedumpfile bug with ppc64 CONFIG_SPARSEMEM_EXTREME Dave Anderson
2013-01-10 21:09 ` Dave Anderson [this message]
2013-01-17 9:36 ` Mahesh Jagannath Salgaonkar
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=1268295784.3657868.1357852163361.JavaMail.root@redhat.com \
--to=anderson@redhat.com \
--cc=caiqian@redhat.com \
--cc=dyoung@redhat.com \
--cc=kexec@lists.infradead.org \
/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.