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.