visible memory seems wrong in kexec crash dump kernel

[Scott Wood]

On 07/31/2013 11:40:05 AM, Friesen, Christopher wrote:
> 
> From: Scott Wood [scottwood at freescale.com]
> Sent: Monday, July 29, 2013 5:10 PM
> To: Friesen, Christopher
> Cc: Michael Ellerman; kexec at lists.infradead.org; Paul Mackerras;  
> linuxppc-dev at 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 support at freescale.com, or to your  
FAE.

-Scott