From: Scott Wood [scottwood@xxxxxxxxxxxxx] 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. 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. This was all on a Wind River Linux 4.3 system, which is based on 2.6.34. It's possible it's been fixed in more recent kernels. The testcase to see if current kernels are still affected should be fairly simple: 1) Take a P5020 board and boot it with NFS rootfs, reserving 224MB for crashkernel. 2) Load a crashkernel into it, configured to use NFS rootfs. 3) Trigger a panic on the main kernel. 4) Ensure it loads the recovery kernel properly, that it is limited to the correct amount of memory, that it has visibility of the original kernel's memory, that it has network connectivity and is stable when copying a few gigs of data over the network. Chris
