All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <5386BA17.3080109@linaro.org>

diff --git a/a/1.txt b/N1/1.txt
index 24ba265..cf1f583 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -16,7 +16,7 @@ On 05/20/2014 12:22 PM, Wang Nan wrote:
 >>> For example:
 >>>
 >>>    For a platform with SECTION_SIZE_BITS == 28 (256MiB) and
->>>    crashkernel=128M@0x28000000 in kernel cmdline, the second
+>>>    crashkernel=128M at 0x28000000 in kernel cmdline, the second
 >>>    kernel is loaded at 0x28000000. Kexec puts elfcorehdr at
 >>>    0x2ff00000, and passes 'elfcorehdr=0x2ff00000 mem=130048K' to
 >>>    second kernel. When second kernel start, it tries to use
@@ -44,7 +44,7 @@ Once device-tree is handled correctly, we don't need to pass "mem=" parameter.
 > Limitation 1: crash kernel reservation kernel must be aligned with 0x08000000 (128MiB).
 >
 >    This is because zImage determine final kernel address by (pc & 0xf8000000). If,
->    for example, set crashkernel=64M@0x29000000, then the second kernel itself
+>    for example, set crashkernel=64M at 0x29000000, then the second kernel itself
 >    overwrites first kernel's memory. We'll lost some memory in /proc/vmcore.
 >
 > Limitation 2: crash kernel must resides in different section with the first kernel.
@@ -66,7 +66,7 @@ I can submit a patch, but can't test it for now.
 -Takahiro AKASHI
 
 
-> In realview board, the only possible correct setting should be 'crashkernel=257M@0x20000000'.
+> In realview board, the only possible correct setting should be 'crashkernel=257M at 0x20000000'.
 > However, realview has only 1GiB memory, crash kernel consumes a quarter plus 1MiB. In addition, even
 > set this parameter, crash kernel is still unusable because:
 >
@@ -79,11 +79,6 @@ I can submit a patch, but can't test it for now.
 >
 > _______________________________________________
 > linux-arm-kernel mailing list
-> linux-arm-kernel@lists.infradead.org
+> linux-arm-kernel at lists.infradead.org
 > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 >
-
-_______________________________________________
-kexec mailing list
-kexec@lists.infradead.org
-http://lists.infradead.org/mailman/listinfo/kexec
diff --git a/a/content_digest b/N1/content_digest
index 45c6efc..efc67fd 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,17 +1,10 @@
  "ref\01400464443-34816-1-git-send-email-wangnan0@huawei.com\0"
  "ref\020140519160947.GM15130@arm.com\0"
  "ref\0537ACA76.3090700@huawei.com\0"
- "From\0AKASHI Takahiro <takahiro.akashi@linaro.org>\0"
- "Subject\0Re: [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid\0"
+ "From\0takahiro.akashi@linaro.org (AKASHI Takahiro)\0"
+ "Subject\0[PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid\0"
  "Date\0Thu, 29 May 2014 13:39:51 +0900\0"
- "To\0Wang Nan <wangnan0@huawei.com>"
- " Will Deacon <will.deacon@arm.com>\0"
- "Cc\0linux@arm.linux.org.uk <linux@arm.linux.org.uk>"
-  kexec@lists.infradead.org <kexec@lists.infradead.org>
-  Geng Hui <hui.geng@huawei.com>
-  Simon Horman <horms@verge.net.au>
-  Andrew Morton <akpm@linux-foundation.org>
- " linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
  "Wang, Will\n"
@@ -32,7 +25,7 @@
  ">>> For example:\n"
  ">>>\n"
  ">>>    For a platform with SECTION_SIZE_BITS == 28 (256MiB) and\n"
- ">>>    crashkernel=128M@0x28000000 in kernel cmdline, the second\n"
+ ">>>    crashkernel=128M at 0x28000000 in kernel cmdline, the second\n"
  ">>>    kernel is loaded at 0x28000000. Kexec puts elfcorehdr at\n"
  ">>>    0x2ff00000, and passes 'elfcorehdr=0x2ff00000 mem=130048K' to\n"
  ">>>    second kernel. When second kernel start, it tries to use\n"
@@ -60,7 +53,7 @@
  "> Limitation 1: crash kernel reservation kernel must be aligned with 0x08000000 (128MiB).\n"
  ">\n"
  ">    This is because zImage determine final kernel address by (pc & 0xf8000000). If,\n"
- ">    for example, set crashkernel=64M@0x29000000, then the second kernel itself\n"
+ ">    for example, set crashkernel=64M at 0x29000000, then the second kernel itself\n"
  ">    overwrites first kernel's memory. We'll lost some memory in /proc/vmcore.\n"
  ">\n"
  "> Limitation 2: crash kernel must resides in different section with the first kernel.\n"
@@ -82,7 +75,7 @@
  "-Takahiro AKASHI\n"
  "\n"
  "\n"
- "> In realview board, the only possible correct setting should be 'crashkernel=257M@0x20000000'.\n"
+ "> In realview board, the only possible correct setting should be 'crashkernel=257M at 0x20000000'.\n"
  "> However, realview has only 1GiB memory, crash kernel consumes a quarter plus 1MiB. In addition, even\n"
  "> set this parameter, crash kernel is still unusable because:\n"
  ">\n"
@@ -95,13 +88,8 @@
  ">\n"
  "> _______________________________________________\n"
  "> linux-arm-kernel mailing list\n"
- "> linux-arm-kernel@lists.infradead.org\n"
+ "> linux-arm-kernel at lists.infradead.org\n"
  "> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel\n"
- ">\n"
- "\n"
- "_______________________________________________\n"
- "kexec mailing list\n"
- "kexec@lists.infradead.org\n"
- http://lists.infradead.org/mailman/listinfo/kexec
+ >
 
-171b296a0e88c46110e5cbec8f95184416bae462b6357c344a682b6223110672
+c1cf6c16107407bf5835f7d482e4acc02d1a3df903746239eacdabac5b709012

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.