diff for duplicates of <5387073C.8080000@huawei.com>

diff --git a/a/1.txt b/N1/1.txt
index 7989a60..15df250 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -17,7 +17,7 @@ On 2014/5/29 12:39, AKASHI Takahiro 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
@@ -45,7 +45,7 @@ On 2014/5/29 12:39, AKASHI Takahiro wrote:
 >> 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.
@@ -74,7 +74,7 @@ before replacement will fail. Finally you will find you still need strict pfn_va
 check whether to use ioremap or use memcpy.
 
 > 
->> 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:
 >>
@@ -87,13 +87,6 @@ check whether to use ioremap or use memcpy.
 >>
 >> _______________________________________________
 >> 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 a46b13a..91419e4 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -2,17 +2,10 @@
  "ref\020140519160947.GM15130@arm.com\0"
  "ref\0537ACA76.3090700@huawei.com\0"
  "ref\05386BA17.3080109@linaro.org\0"
- "From\0Wang Nan <wangnan0@huawei.com>\0"
- "Subject\0Re: [PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid\0"
+ "From\0wangnan0@huawei.com (Wang Nan)\0"
+ "Subject\0[PATCH Resend] ARM: kdump: makes second kernel use strict pfn_valid\0"
  "Date\0Thu, 29 May 2014 18:09:00 +0800\0"
- "To\0AKASHI Takahiro <takahiro.akashi@linaro.org>"
- " 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>
-  genghui 00204690 <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"
  "On 2014/5/29 12:39, AKASHI Takahiro wrote:\n"
@@ -34,7 +27,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"
@@ -62,7 +55,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"
@@ -91,7 +84,7 @@
  "check whether to use ioremap or use memcpy.\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"
@@ -104,15 +97,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"
- "\n"
- "_______________________________________________\n"
- "kexec mailing list\n"
- "kexec@lists.infradead.org\n"
- http://lists.infradead.org/mailman/listinfo/kexec
+ >>
 
-96c3e604a4fafaa2700c2efe0ef70777deb0f54007c21edb017b9f72ffcdc247
+040ba487764361a3a808da229e5b81df3a3f0e186caae1a2745489fc577496e6
