All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1375289450.30721.93@snotra>

diff --git a/a/1.txt b/N1/1.txt
index bbcf443..1c3f03b 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -1,14 +1,14 @@
 On 07/31/2013 11:40:05 AM, Friesen, Christopher wrote:
-> 
+>=20
 > From: Scott Wood [scottwood@freescale.com]
 > Sent: Monday, July 29, 2013 5:10 PM
 > To: Friesen, Christopher
-> Cc: Michael Ellerman; kexec@lists.infradead.org; Paul Mackerras;  
+> Cc: Michael Ellerman; kexec@lists.infradead.org; Paul Mackerras; =20
 > linuxppc-dev@lists.ozlabs.org; Vivek Goyal
 > Subject: Re: visible memory seems wrong in kexec crash dump kernel
-> 
+>=20
 > On 07/13/2013 01:30:50 AM, Chris Friesen wrote:
-> > The upshot is that there seems to be a number of things that could  
+> > The upshot is that there seems to be a number of things that could =20
 > be
 > > improved:
 > >
@@ -16,39 +16,34 @@ On 07/31/2013 11:40:05 AM, Friesen, Christopher wrote:
 > > 2) lmb_reserve() should really respect the crashkernel memory limit
 > > 3) the freescale stuff really shouldn't assume it can map things
 > > wherever it feels like
-> 
+>=20
 > What "board-specific freescale code" are you referring to?
-> 
+>=20
 > -Scott
-> 
-> 
+>=20
+>=20
 > Sorry for the crappy quoting, I'm using a web outlook portal.
-> 
-> I've switched employers so I don't have access to the exact details  
-> any more.  The system in question was a Kontron AM4150 which uses the  
-> P5020.  As I recall, one of the Freescale drivers (I think it was the  
-> buffer or queue manager that the network driver makes use of) was  
-> attempting to call lmb_reserve() with a base address in the 4GB range  
+>=20
+> I've switched employers so I don't have access to the exact details =20
+> any more.  The system in question was a Kontron AM4150 which uses the =20
+> P5020.  As I recall, one of the Freescale drivers (I think it was the =20
+> buffer or queue manager that the network driver makes use of) was =20
+> attempting to call lmb_reserve() with a base address in the 4GB range =20
 > even though the recovery kernel was limited to 224MB of memory.
 
-That's not "board specific" code, and it's not even mainline Linux  
+That's not "board specific" code, and it's not even mainline Linux =20
 code.  Unfortunately none of the datapath stuff is upstream, still.
 
-> While I've got your attention, the other thing that I found was that  
-> the "dpa" network driver didn't properly work in a kexec'd kernel  
-> even when given lots of memory.  It would work for a little bit and  
+> While I've got your attention, the other thing that I found was that =20
+> the "dpa" network driver didn't properly work in a kexec'd kernel =20
+> even when given lots of memory.  It would work for a little bit and =20
 > then hang.
 
-I'm not particularly surprised by this.  It doesn't help that there's  
+I'm not particularly surprised by this.  It doesn't help that there's =20
 no way to do a device reset. :-(
 
-Issues with Freescale SDK code should be reported on  
-https://community.freescale.com/, to support@freescale.com, or to your  
+Issues with Freescale SDK code should be reported on =20
+https://community.freescale.com/, to support@freescale.com, or to your =20
 FAE.
 
--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 b413bb6..fd35994 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -4,24 +4,23 @@
  "Date\0Wed, 31 Jul 2013 11:50:50 -0500\0"
  "To\0Friesen"
  " Christopher <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 <kexec@lists.infradead.org>
   linuxppc-dev@lists.ozlabs.org <linuxppc-dev@lists.ozlabs.org>
  " Vivek Goyal <vgoyal@redhat.com>\0"
  "\00:1\0"
  "b\0"
  "On 07/31/2013 11:40:05 AM, Friesen, Christopher wrote:\n"
- "> \n"
+ ">=20\n"
  "> From: Scott Wood [scottwood@freescale.com]\n"
  "> Sent: Monday, July 29, 2013 5:10 PM\n"
  "> To: Friesen, Christopher\n"
- "> Cc: Michael Ellerman; kexec@lists.infradead.org; Paul Mackerras;  \n"
+ "> Cc: Michael Ellerman; kexec@lists.infradead.org; Paul Mackerras; =20\n"
  "> linuxppc-dev@lists.ozlabs.org; Vivek Goyal\n"
  "> Subject: Re: visible memory seems wrong in kexec crash dump kernel\n"
- "> \n"
+ ">=20\n"
  "> On 07/13/2013 01:30:50 AM, Chris Friesen wrote:\n"
- "> > The upshot is that there seems to be a number of things that could  \n"
+ "> > The upshot is that there seems to be a number of things that could =20\n"
  "> be\n"
  "> > improved:\n"
  "> >\n"
@@ -29,41 +28,36 @@
  "> > 2) lmb_reserve() should really respect the crashkernel memory limit\n"
  "> > 3) the freescale stuff really shouldn't assume it can map things\n"
  "> > wherever it feels like\n"
- "> \n"
+ ">=20\n"
  "> What \"board-specific freescale code\" are you referring to?\n"
- "> \n"
+ ">=20\n"
  "> -Scott\n"
- "> \n"
- "> \n"
+ ">=20\n"
+ ">=20\n"
  "> Sorry for the crappy quoting, I'm using a web outlook portal.\n"
- "> \n"
- "> I've switched employers so I don't have access to the exact details  \n"
- "> any more.  The system in question was a Kontron AM4150 which uses the  \n"
- "> P5020.  As I recall, one of the Freescale drivers (I think it was the  \n"
- "> buffer or queue manager that the network driver makes use of) was  \n"
- "> attempting to call lmb_reserve() with a base address in the 4GB range  \n"
+ ">=20\n"
+ "> I've switched employers so I don't have access to the exact details =20\n"
+ "> any more.  The system in question was a Kontron AM4150 which uses the =20\n"
+ "> P5020.  As I recall, one of the Freescale drivers (I think it was the =20\n"
+ "> buffer or queue manager that the network driver makes use of) was =20\n"
+ "> attempting to call lmb_reserve() with a base address in the 4GB range =20\n"
  "> even though the recovery kernel was limited to 224MB of memory.\n"
  "\n"
- "That's not \"board specific\" code, and it's not even mainline Linux  \n"
+ "That's not \"board specific\" code, and it's not even mainline Linux =20\n"
  "code.  Unfortunately none of the datapath stuff is upstream, still.\n"
  "\n"
- "> While I've got your attention, the other thing that I found was that  \n"
- "> the \"dpa\" network driver didn't properly work in a kexec'd kernel  \n"
- "> even when given lots of memory.  It would work for a little bit and  \n"
+ "> While I've got your attention, the other thing that I found was that =20\n"
+ "> the \"dpa\" network driver didn't properly work in a kexec'd kernel =20\n"
+ "> even when given lots of memory.  It would work for a little bit and =20\n"
  "> then hang.\n"
  "\n"
- "I'm not particularly surprised by this.  It doesn't help that there's  \n"
+ "I'm not particularly surprised by this.  It doesn't help that there's =20\n"
  "no way to do a device reset. :-(\n"
  "\n"
- "Issues with Freescale SDK code should be reported on  \n"
- "https://community.freescale.com/, to support@freescale.com, or to your  \n"
+ "Issues with Freescale SDK code should be reported on =20\n"
+ "https://community.freescale.com/, to support@freescale.com, or to your =20\n"
  "FAE.\n"
  "\n"
- "-Scott\n"
- "\n"
- "_______________________________________________\n"
- "kexec mailing list\n"
- "kexec@lists.infradead.org\n"
- http://lists.infradead.org/mailman/listinfo/kexec
+ -Scott=
 
-bc13effb1007eac08ea5794787d9ef2d508d14ea5c32f8744e75fb24da091ca4
+e0fdaebb6c46b8790ccc0fda854415670fc8dd2b42efd68ba919f105f13cc747

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.