diff for duplicates of <537D58AF.4080404@huawei.com>

diff --git a/a/1.txt b/N1/1.txt
index ad5b68e..56a9fc6 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -18,7 +18,7 @@ On 2014/5/20 11:22, 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
@@ -42,7 +42,7 @@ On 2014/5/20 11:22, Wang Nan 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.
@@ -58,7 +58,7 @@ On 2014/5/20 11:22, Wang Nan wrote:
 >   simply uses the last 1MiB for it. The second kernel use ioremap to access it, force
 >   the header be put in another section.
 > 
-> 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:
 > 
@@ -71,13 +71,6 @@ On 2014/5/20 11:22, Wang Nan wrote:
 > 
 > _______________________________________________
 > kexec mailing list
-> kexec@lists.infradead.org
+> kexec at lists.infradead.org
 > http://lists.infradead.org/mailman/listinfo/kexec
-> 
-
-
-
-_______________________________________________
-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 9eb3584..ab0c25b 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,16 +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\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, 22 May 2014 09:53:51 +0800\0"
- "To\0Will 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"
  "Hi Will,\n"
@@ -33,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"
@@ -57,7 +51,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"
@@ -73,7 +67,7 @@
  ">   simply uses the last 1MiB for it. The second kernel use ioremap to access it, force\n"
  ">   the header be put in another section.\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"
@@ -86,15 +80,8 @@
  "> \n"
  "> _______________________________________________\n"
  "> kexec mailing list\n"
- "> kexec@lists.infradead.org\n"
+ "> kexec at lists.infradead.org\n"
  "> http://lists.infradead.org/mailman/listinfo/kexec\n"
- "> \n"
- "\n"
- "\n"
- "\n"
- "_______________________________________________\n"
- "kexec mailing list\n"
- "kexec@lists.infradead.org\n"
- http://lists.infradead.org/mailman/listinfo/kexec
+ >
 
-8714af153fd790466a95945ba6da354469bb9c657d4b6f8490cab445a916bc75
+559428f9dcdf3eecaae7006d43aac481947f179c84c670b1c5b7fca1671434e8
