On 07/31/2013 11:40:05 AM, Friesen, Christopher wrote:
From: Scott Wood [scottw...@freescale.com]
Sent: Monday, July 29, 2013 5:10 PM
To: Friesen, Christopher
Cc: Michael Ellerman; ke...@lists.infradead.org; Paul Mackerras;
linuxppc-dev@lists.ozlabs.org; Vivek Goyal
Subject: Re: visible memory seems wrong in kexec crash dump kernel
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
be
> improved:
>
> 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
> wherever it feels like
What "board-specific freescale code" are you referring to?
-Scott
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
even though the recovery kernel was limited to 224MB of memory.
That's not "board specific" code, and it's not even mainline Linux
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
then hang.
I'm not particularly surprised by this. It doesn't help that there's
no way to do a device reset. :-(
Issues with Freescale SDK code should be reported on
https://community.freescale.com/, to supp...@freescale.com, or to your
FAE.
-Scott
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev