diff for duplicates of <1375139436.30721.63@snotra>

diff --git a/a/1.txt b/N1/1.txt
index edb602e..28d9f66 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,72 +1,67 @@
 On 07/13/2013 01:30:50 AM, Chris Friesen wrote:
 > On 07/12/2013 04:59 PM, Chris Friesen wrote:
 >> On 07/12/2013 03:08 PM, Chris Friesen wrote:
->> 
->>> I turned on the instrumentation in early_init_dt_scan_memory() and  
+>>=20
+>>> I turned on the instrumentation in early_init_dt_scan_memory() and =20
 >>> got
 >>> the following when jumping to the capture kernel:
->>> 
+>>>=20
 >>> memory scan node memory, reg size 16, data: 0 0 2 0,
 >>> - 0 , 200000000
->>> 
+>>>=20
 >>> That 0x200000000 matches the fact that I'm seeing 8GB of memory
 >>> available in the recovery kernel.
->>> 
->>> If I boot the original kernel with "crashkernel=224M@32M", should I
+>>>=20
+>>> If I boot the original kernel with "crashkernel=3D224M@32M", should I
 >>> expect that only 224MB is marked as "linux,usable-memory" in the
 >>> recovery kernel?
->> 
->> I started looking at the kexec side of things, and I noticed  
+>>=20
+>> I started looking at the kexec side of things, and I noticed =20
 >> something a
->> bit odd. In most places dealing with the device tree in kexec it  
+>> bit odd. In most places dealing with the device tree in kexec it =20
 >> accepts
 >> either "memory" or "memory@" for the memory node name. In
->> add_usable_mem_property() in arch/ppc64/fs2dt.c it seems to only  
+>> add_usable_mem_property() in arch/ppc64/fs2dt.c it seems to only =20
 >> accept
 >> "memory@".
->> 
+>>=20
 >> Is this expected behaviour? It seems to be the same in current git
 >> versions of kexec-tools.
->> 
+>>=20
 >> On my system I see "/proc/device-tree/memory".
->> 
->> If I modify add_usable_mem_property() to also accept "/memory" then  
+>>=20
+>> If I modify add_usable_mem_property() to also accept "/memory" then =20
 >> my
 >> recovery kernel boots up with
->> 
->> physicalMemorySize = 0x10000000
->> 
->> which is 256MB (which is still a bit odd since I specified 224MB for  
+>>=20
+>> physicalMemorySize =3D 0x10000000
+>>=20
+>> which is 256MB (which is still a bit odd since I specified 224MB for =20
 >> the
 >> crashkernel).
->> 
+>>=20
 >> However, it then hits the BUG() call at the end of mark_bootmem() in
 >> mm/bootmem.c.
-> 
+>=20
 > One final thing and I'll stop replying to myself. :)
-> 
-> It looks like the problem is that some board-specific freescale code  
-> was calling lmb_reserve() with a base address in the 4GB range.  It  
-> seems odd that lmb_reserve() didn't throw some kind of error when the  
+>=20
+> It looks like the problem is that some board-specific freescale code =20
+> was calling lmb_reserve() with a base address in the 4GB range.  It =20
+> seems odd that lmb_reserve() didn't throw some kind of error when the =20
 > recovery kernel was supposed to be limited to 224MB.
-> 
-> Rather than try and fix the bug, I turned off the (unneeded) config  
-> options related to the above lmb_reserve() calls and was able to  
+>=20
+> Rather than try and fix the bug, I turned off the (unneeded) config =20
+> options related to the above lmb_reserve() calls and was able to =20
 > successfully access the information I needed via /dev/oldmem.
-> 
-> The upshot is that there seems to be a number of things that could be  
+>=20
+> The upshot is that there seems to be a number of things that could be =20
 > improved:
-> 
+>=20
 > 1) kexec should accept "/memory" and not just "/memory@"
 > 2) lmb_reserve() should really respect the crashkernel memory limit
-> 3) the freescale stuff really shouldn't assume it can map things  
+> 3) the freescale stuff really shouldn't assume it can map things =20
 > wherever it feels like
 
 What "board-specific freescale code" are you referring to?
 
--Scott
-
-_______________________________________________
-kexec mailing list
-kexec@lists.infradead.org
-http://lists.infradead.org/mailman/listinfo/kexec
+-Scott=
diff --git a/a/content_digest b/N1/content_digest
index 03cca40..c82edff 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -3,8 +3,7 @@
  "Subject\0Re: visible memory seems wrong in kexec crash dump kernel\0"
  "Date\0Mon, 29 Jul 2013 18:10:36 -0500\0"
  "To\0Chris Friesen <cbf123@mail.usask.ca>\0"
- "Cc\0Michael Ellerman <michael@ellerman.id.au>"
-  Paul Mackerras <paulus@samba.org>
+ "Cc\0Paul Mackerras <paulus@samba.org>"
   kexec@lists.infradead.org
   linuxppc-dev@lists.ozlabs.org
  " Vivek Goyal <vgoyal@redhat.com>\0"
@@ -13,74 +12,69 @@
  "On 07/13/2013 01:30:50 AM, Chris Friesen wrote:\n"
  "> On 07/12/2013 04:59 PM, Chris Friesen wrote:\n"
  ">> On 07/12/2013 03:08 PM, Chris Friesen wrote:\n"
- ">> \n"
- ">>> I turned on the instrumentation in early_init_dt_scan_memory() and  \n"
+ ">>=20\n"
+ ">>> I turned on the instrumentation in early_init_dt_scan_memory() and =20\n"
  ">>> got\n"
  ">>> the following when jumping to the capture kernel:\n"
- ">>> \n"
+ ">>>=20\n"
  ">>> memory scan node memory, reg size 16, data: 0 0 2 0,\n"
  ">>> - 0 , 200000000\n"
- ">>> \n"
+ ">>>=20\n"
  ">>> That 0x200000000 matches the fact that I'm seeing 8GB of memory\n"
  ">>> available in the recovery kernel.\n"
- ">>> \n"
- ">>> If I boot the original kernel with \"crashkernel=224M@32M\", should I\n"
+ ">>>=20\n"
+ ">>> If I boot the original kernel with \"crashkernel=3D224M@32M\", should I\n"
  ">>> expect that only 224MB is marked as \"linux,usable-memory\" in the\n"
  ">>> recovery kernel?\n"
- ">> \n"
- ">> I started looking at the kexec side of things, and I noticed  \n"
+ ">>=20\n"
+ ">> I started looking at the kexec side of things, and I noticed =20\n"
  ">> something a\n"
- ">> bit odd. In most places dealing with the device tree in kexec it  \n"
+ ">> bit odd. In most places dealing with the device tree in kexec it =20\n"
  ">> accepts\n"
  ">> either \"memory\" or \"memory@\" for the memory node name. In\n"
- ">> add_usable_mem_property() in arch/ppc64/fs2dt.c it seems to only  \n"
+ ">> add_usable_mem_property() in arch/ppc64/fs2dt.c it seems to only =20\n"
  ">> accept\n"
  ">> \"memory@\".\n"
- ">> \n"
+ ">>=20\n"
  ">> Is this expected behaviour? It seems to be the same in current git\n"
  ">> versions of kexec-tools.\n"
- ">> \n"
+ ">>=20\n"
  ">> On my system I see \"/proc/device-tree/memory\".\n"
- ">> \n"
- ">> If I modify add_usable_mem_property() to also accept \"/memory\" then  \n"
+ ">>=20\n"
+ ">> If I modify add_usable_mem_property() to also accept \"/memory\" then =20\n"
  ">> my\n"
  ">> recovery kernel boots up with\n"
- ">> \n"
- ">> physicalMemorySize = 0x10000000\n"
- ">> \n"
- ">> which is 256MB (which is still a bit odd since I specified 224MB for  \n"
+ ">>=20\n"
+ ">> physicalMemorySize =3D 0x10000000\n"
+ ">>=20\n"
+ ">> which is 256MB (which is still a bit odd since I specified 224MB for =20\n"
  ">> the\n"
  ">> crashkernel).\n"
- ">> \n"
+ ">>=20\n"
  ">> However, it then hits the BUG() call at the end of mark_bootmem() in\n"
  ">> mm/bootmem.c.\n"
- "> \n"
+ ">=20\n"
  "> One final thing and I'll stop replying to myself. :)\n"
- "> \n"
- "> It looks like the problem is that some board-specific freescale code  \n"
- "> was calling lmb_reserve() with a base address in the 4GB range.  It  \n"
- "> seems odd that lmb_reserve() didn't throw some kind of error when the  \n"
+ ">=20\n"
+ "> It looks like the problem is that some board-specific freescale code =20\n"
+ "> was calling lmb_reserve() with a base address in the 4GB range.  It =20\n"
+ "> seems odd that lmb_reserve() didn't throw some kind of error when the =20\n"
  "> recovery kernel was supposed to be limited to 224MB.\n"
- "> \n"
- "> Rather than try and fix the bug, I turned off the (unneeded) config  \n"
- "> options related to the above lmb_reserve() calls and was able to  \n"
+ ">=20\n"
+ "> Rather than try and fix the bug, I turned off the (unneeded) config =20\n"
+ "> options related to the above lmb_reserve() calls and was able to =20\n"
  "> successfully access the information I needed via /dev/oldmem.\n"
- "> \n"
- "> The upshot is that there seems to be a number of things that could be  \n"
+ ">=20\n"
+ "> The upshot is that there seems to be a number of things that could be =20\n"
  "> improved:\n"
- "> \n"
+ ">=20\n"
  "> 1) kexec should accept \"/memory\" and not just \"/memory@\"\n"
  "> 2) lmb_reserve() should really respect the crashkernel memory limit\n"
- "> 3) the freescale stuff really shouldn't assume it can map things  \n"
+ "> 3) the freescale stuff really shouldn't assume it can map things =20\n"
  "> wherever it feels like\n"
  "\n"
  "What \"board-specific freescale code\" are you referring to?\n"
  "\n"
- "-Scott\n"
- "\n"
- "_______________________________________________\n"
- "kexec mailing list\n"
- "kexec@lists.infradead.org\n"
- http://lists.infradead.org/mailman/listinfo/kexec
+ -Scott=
 
-d4756ef3984c810b749b07e2896949ec82995a37d6c8f960a9e843a94206dea5
+fb3bfe5df40802b7bfa66bc3e0e93f6fc6feb9b9135745acd1afb4dc93f46b3c
