From: Xishi Qiu <qiuxishi@huawei.com>
To: "Luck, Tony" <tony.luck@intel.com>,
vgoyal@redhat.com, hbabu@us.ibm.com, rob@landley.net
Cc: linux-ia64@vger.kernel.org, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: [PATCH] ia64/mm: add size restriction to the kdump
Date: Mon, 25 Mar 2013 19:14:16 +0800 [thread overview]
Message-ID: <51503188.8060706@huawei.com> (raw)
In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set "crashkernel=1024M-:600M"
and use sparse memory model, when crash kernel booting it changes [128M-728M] to [128M-720M].
But initrd memory is in [709M-727M], and virt_addr_valid() *can not* check the invalid pages
when freeing initrd memory, because there are some pages missed at the end of the seciton,
and this causes error.
...
Unpacking initramfs...
Freeing initrd memory: 19648kB freed
BUG: Bad page state in process swapper pfn:02d00
page:e0000000102dd800 flags:(null) count:0 mapcount:1 mapping:(null) index:0
Call Trace:
[<a000000100018dc0>] show_stack+0x80/0xa0
sp=e000000021e8fbd0 bsp=e000000021e81360
[<a00000010090fcc0>] dump_stack+0x30/0x50
sp=e000000021e8fda0 bsp=e000000021e81348
[<a0000001001a3180>] bad_page+0x280/0x380
sp=e000000021e8fda0 bsp=e000000021e81308
[<a0000001001a8740>] free_hot_cold_page+0x3a0/0x5c0
sp=e000000021e8fda0 bsp=e000000021e812a0
[<a0000001001a8a50>] free_hot_page+0x30/0x60
sp=e000000021e8fda0 bsp=e000000021e81280
[<a0000001001a8b30>] __free_pages+0xb0/0xe0
sp=e000000021e8fda0 bsp=e000000021e81258
[<a0000001001a8c00>] free_pages+0xa0/0xc0
sp=e000000021e8fda0 bsp=e000000021e81230
[<a000000100bb40c0>] free_initrd_mem+0x230/0x290
sp=e000000021e8fda0 bsp=e000000021e811d8
[<a000000100ba6620>] populate_rootfs+0x1c0/0x280
sp=e000000021e8fdb0 bsp=e000000021e811a0
[<a00000010000ac30>] do_one_initcall+0x3b0/0x3e0
sp=e000000021e8fdb0 bsp=e000000021e81158
[<a000000100ba0a90>] kernel_init+0x3f0/0x4b0
sp=e000000021e8fdb0 bsp=e000000021e81108
[<a000000100016890>] kernel_thread_helper+0xd0/0x100
sp=e000000021e8fe30 bsp=e000000021e810e0
[<a00000010000a4c0>] start_kernel_thread+0x20/0x40
sp=e000000021e8fe30 bsp=e000000021e810e0
...
In "http://marc.info/?l=linux-arch&m=136147092429314&w=2" Tony said:
"Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry
in kernel-parameters.txt points at). The ia64 section of kdump.txt
notes that the start address will be rounded up to a GRANULE boundary,
but doesn't talk about restrictions on the size."
This patch add size restriction to the documentation of kdump.
Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
Documentation/kdump/kdump.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 13f1aa0..9c7fd98 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -297,6 +297,7 @@ Boot into System Kernel
On ia64, 256M@256M is a generous value that typically works.
The region may be automatically placed on ia64, see the
dump-capture kernel config option notes above.
+ If use sparse memory, the size should be rounded to GRANULE boundaries.
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
on the memory consumption of the kdump system. In general this is not
--
1.7.6.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: "Luck, Tony" <tony.luck@intel.com>,
vgoyal@redhat.com, hbabu@us.ibm.com, rob@landley.net
Cc: kexec@lists.infradead.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: [PATCH] ia64/mm: add size restriction to the kdump
Date: Mon, 25 Mar 2013 11:14:16 +0000 [thread overview]
Message-ID: <51503188.8060706@huawei.com> (raw)
In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set "crashkernel\x1024M-:600M"
and use sparse memory model, when crash kernel booting it changes [128M-728M] to [128M-720M].
But initrd memory is in [709M-727M], and virt_addr_valid() *can not* check the invalid pages
when freeing initrd memory, because there are some pages missed at the end of the seciton,
and this causes error.
...
Unpacking initramfs...
Freeing initrd memory: 19648kB freed
BUG: Bad page state in process swapper pfn:02d00
page:e0000000102dd800 flags:(null) count:0 mapcount:1 mapping:(null) index:0
Call Trace:
[<a000000100018dc0>] show_stack+0x80/0xa0
spà00000021e8fbd0 bspà00000021e81360
[<a00000010090fcc0>] dump_stack+0x30/0x50
spà00000021e8fda0 bspà00000021e81348
[<a0000001001a3180>] bad_page+0x280/0x380
spà00000021e8fda0 bspà00000021e81308
[<a0000001001a8740>] free_hot_cold_page+0x3a0/0x5c0
spà00000021e8fda0 bspà00000021e812a0
[<a0000001001a8a50>] free_hot_page+0x30/0x60
spà00000021e8fda0 bspà00000021e81280
[<a0000001001a8b30>] __free_pages+0xb0/0xe0
spà00000021e8fda0 bspà00000021e81258
[<a0000001001a8c00>] free_pages+0xa0/0xc0
spà00000021e8fda0 bspà00000021e81230
[<a000000100bb40c0>] free_initrd_mem+0x230/0x290
spà00000021e8fda0 bspà00000021e811d8
[<a000000100ba6620>] populate_rootfs+0x1c0/0x280
spà00000021e8fdb0 bspà00000021e811a0
[<a00000010000ac30>] do_one_initcall+0x3b0/0x3e0
spà00000021e8fdb0 bspà00000021e81158
[<a000000100ba0a90>] kernel_init+0x3f0/0x4b0
spà00000021e8fdb0 bspà00000021e81108
[<a000000100016890>] kernel_thread_helper+0xd0/0x100
spà00000021e8fe30 bspà00000021e810e0
[<a00000010000a4c0>] start_kernel_thread+0x20/0x40
spà00000021e8fe30 bspà00000021e810e0
...
In "http://marc.info/?l=linux-arch&m\x136147092429314&w=2" Tony said:
"Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry
in kernel-parameters.txt points at). The ia64 section of kdump.txt
notes that the start address will be rounded up to a GRANULE boundary,
but doesn't talk about restrictions on the size."
This patch add size restriction to the documentation of kdump.
Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
Documentation/kdump/kdump.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 13f1aa0..9c7fd98 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -297,6 +297,7 @@ Boot into System Kernel
On ia64, 256M@256M is a generous value that typically works.
The region may be automatically placed on ia64, see the
dump-capture kernel config option notes above.
+ If use sparse memory, the size should be rounded to GRANULE boundaries.
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
on the memory consumption of the kdump system. In general this is not
--
1.7.6.1
WARNING: multiple messages have this Message-ID (diff)
From: Xishi Qiu <qiuxishi@huawei.com>
To: "Luck, Tony" <tony.luck@intel.com>, <vgoyal@redhat.com>,
<hbabu@us.ibm.com>, <rob@landley.net>
Cc: <kexec@lists.infradead.org>, <linux-doc@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <linux-ia64@vger.kernel.org>
Subject: [PATCH] ia64/mm: add size restriction to the kdump
Date: Mon, 25 Mar 2013 19:14:16 +0800 [thread overview]
Message-ID: <51503188.8060706@huawei.com> (raw)
In efi_init() memory aligns in IA64_GRANULE_SIZE(16M). If set "crashkernel=1024M-:600M"
and use sparse memory model, when crash kernel booting it changes [128M-728M] to [128M-720M].
But initrd memory is in [709M-727M], and virt_addr_valid() *can not* check the invalid pages
when freeing initrd memory, because there are some pages missed at the end of the seciton,
and this causes error.
...
Unpacking initramfs...
Freeing initrd memory: 19648kB freed
BUG: Bad page state in process swapper pfn:02d00
page:e0000000102dd800 flags:(null) count:0 mapcount:1 mapping:(null) index:0
Call Trace:
[<a000000100018dc0>] show_stack+0x80/0xa0
sp=e000000021e8fbd0 bsp=e000000021e81360
[<a00000010090fcc0>] dump_stack+0x30/0x50
sp=e000000021e8fda0 bsp=e000000021e81348
[<a0000001001a3180>] bad_page+0x280/0x380
sp=e000000021e8fda0 bsp=e000000021e81308
[<a0000001001a8740>] free_hot_cold_page+0x3a0/0x5c0
sp=e000000021e8fda0 bsp=e000000021e812a0
[<a0000001001a8a50>] free_hot_page+0x30/0x60
sp=e000000021e8fda0 bsp=e000000021e81280
[<a0000001001a8b30>] __free_pages+0xb0/0xe0
sp=e000000021e8fda0 bsp=e000000021e81258
[<a0000001001a8c00>] free_pages+0xa0/0xc0
sp=e000000021e8fda0 bsp=e000000021e81230
[<a000000100bb40c0>] free_initrd_mem+0x230/0x290
sp=e000000021e8fda0 bsp=e000000021e811d8
[<a000000100ba6620>] populate_rootfs+0x1c0/0x280
sp=e000000021e8fdb0 bsp=e000000021e811a0
[<a00000010000ac30>] do_one_initcall+0x3b0/0x3e0
sp=e000000021e8fdb0 bsp=e000000021e81158
[<a000000100ba0a90>] kernel_init+0x3f0/0x4b0
sp=e000000021e8fdb0 bsp=e000000021e81108
[<a000000100016890>] kernel_thread_helper+0xd0/0x100
sp=e000000021e8fe30 bsp=e000000021e810e0
[<a00000010000a4c0>] start_kernel_thread+0x20/0x40
sp=e000000021e8fe30 bsp=e000000021e810e0
...
In "http://marc.info/?l=linux-arch&m=136147092429314&w=2" Tony said:
"Perhaps in Documentation/kdump/kdump.txt (which the crashkernel entry
in kernel-parameters.txt points at). The ia64 section of kdump.txt
notes that the start address will be rounded up to a GRANULE boundary,
but doesn't talk about restrictions on the size."
This patch add size restriction to the documentation of kdump.
Signed-off-by: Xishi Qiu <qiuxishi@huawei.com>
---
Documentation/kdump/kdump.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 13f1aa0..9c7fd98 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -297,6 +297,7 @@ Boot into System Kernel
On ia64, 256M@256M is a generous value that typically works.
The region may be automatically placed on ia64, see the
dump-capture kernel config option notes above.
+ If use sparse memory, the size should be rounded to GRANULE boundaries.
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
on the memory consumption of the kdump system. In general this is not
--
1.7.6.1
next reply other threads:[~2013-03-25 11:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-25 11:14 Xishi Qiu [this message]
2013-03-25 11:14 ` [PATCH] ia64/mm: add size restriction to the kdump Xishi Qiu
2013-03-25 11:14 ` Xishi Qiu
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=51503188.8060706@huawei.com \
--to=qiuxishi@huawei.com \
--cc=hbabu@us.ibm.com \
--cc=kexec@lists.infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rob@landley.net \
--cc=tony.luck@intel.com \
--cc=vgoyal@redhat.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.