diff for duplicates of <53746D32.4000708@huawei.com>

diff --git a/a/1.txt b/N1/1.txt
index c4075ac..fe6ea97 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,4 +1,4 @@
-Add kexec@lists.infradead.org to cc list.
+Add kexec at lists.infradead.org to cc list.
 
 On 2014/5/15 15:14, Wang Nan wrote:
 > This patch makes crash dump kernel use arch pfn_valid defined in
@@ -13,7 +13,7 @@ On 2014/5/15 15:14, Wang Nan wrote:
 > some limitations on positioning the crash kernel. 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
@@ -22,7 +22,7 @@ On 2014/5/15 15:14, Wang Nan wrote:
 >   the page as valid, so ioremap will refuse to map it.
 > 
 > Even if we put crash kernel at the boundary of two sections (such as
-> 129MB@0x0x28000000 in the above situation), 0x20000000-0x28000000 used
+> 129MB at 0x0x28000000 in the above situation), 0x20000000-0x28000000 used
 > by old kernel is still unable to retrived by crash kernel because they
 > are at the same section.
 > 
@@ -50,11 +50,4 @@ On 2014/5/15 15:14, Wang Nan wrote:
 >  
 >  config HIGHMEM
 >  	bool "High Memory Support"
-> 
-
-
-
-_______________________________________________
-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 bb67163..8664350 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -1,19 +1,11 @@
  "ref\01400138070-24046-1-git-send-email-wangnan0@huawei.com\0"
- "From\0Wang Nan <wangnan0@huawei.com>\0"
- "Subject\0Re: [PATCH] crash_dump: arm: crash dump kernel should use strict pfn_valid\0"
+ "From\0wangnan0@huawei.com (Wang Nan)\0"
+ "Subject\0[PATCH] crash_dump: arm: crash dump kernel should use strict pfn_valid\0"
  "Date\0Thu, 15 May 2014 15:30:58 +0800\0"
- "To\0Wang Nan <wangnan0@huawei.com>"
-  Russell King <linux@arm.linux.org.uk>
-  Will Deacon <will.deacon@arm.com>
-  Simon Horman <horms@verge.net.au>
- " Mika Westerberg <ext-mika.1.westerberg@nokia.com>\0"
- "Cc\0kexec@lists.infradead.org <kexec@lists.infradead.org>"
-  linux-kernel@vger.kernel.org
-  linux-arm-kernel@lists.infradead.org
- " Geng Hui <hui.geng@huawei.com>\0"
+ "To\0linux-arm-kernel@lists.infradead.org\0"
  "\00:1\0"
  "b\0"
- "Add kexec@lists.infradead.org to cc list.\n"
+ "Add kexec at lists.infradead.org to cc list.\n"
  "\n"
  "On 2014/5/15 15:14, Wang Nan wrote:\n"
  "> This patch makes crash dump kernel use arch pfn_valid defined in\n"
@@ -28,7 +20,7 @@
  "> some limitations on positioning the crash kernel. 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"
@@ -37,7 +29,7 @@
  ">   the page as valid, so ioremap will refuse to map it.\n"
  "> \n"
  "> Even if we put crash kernel at the boundary of two sections (such as\n"
- "> 129MB@0x0x28000000 in the above situation), 0x20000000-0x28000000 used\n"
+ "> 129MB at 0x0x28000000 in the above situation), 0x20000000-0x28000000 used\n"
  "> by old kernel is still unable to retrived by crash kernel because they\n"
  "> are at the same section.\n"
  "> \n"
@@ -65,13 +57,6 @@
  ">  \n"
  ">  config HIGHMEM\n"
  ">  \tbool \"High Memory Support\"\n"
- "> \n"
- "\n"
- "\n"
- "\n"
- "_______________________________________________\n"
- "kexec mailing list\n"
- "kexec@lists.infradead.org\n"
- http://lists.infradead.org/mailman/listinfo/kexec
+ >
 
-b78aeb0f42e43e8417af7b5e17101f49884f1be5dc810e938cbd0ce5134d53ab
+4115206b2fdb9ba61ca20a561c0bc4db6582f8049110b0baa9da872c316b5f31
