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
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
On 07/13/2013 01:30:50 AM, Chris Friesen wrote:
On 07/12/2013 04:59 PM, Chris Friesen wrote:
On 07/12/2013 03:08 PM, Chris Friesen wrote:
I turned on the instrumentation in early_init_dt_scan_memory() and
got
the following when jumping to the capture kernel:
memory scan node memory, reg
On 07/13/2013 11:26 PM, Benjamin Herrenschmidt wrote:
On Sun, 2013-07-14 at 14:36 +1000, Michael Ellerman wrote:
Is this expected behaviour? It seems to be the same in current git
versions of kexec-tools.
On my system I see /proc/device-tree/memory.
If I modify add_usable_mem_property() to
On Sun, 2013-07-14 at 17:08 -0600, Chris Friesen wrote:
So for memory starting at 0 it should be memory@0
There are a fair number of dts files in the kernel tree that don't
specify an address for the memory node.
If the kernel accepts it without an address, it seems logical that kexec
On 07/12/2013 04:59 PM, Chris Friesen wrote:
On 07/12/2013 03:08 PM, Chris Friesen wrote:
I turned on the instrumentation in early_init_dt_scan_memory() and got
the following when jumping to the capture kernel:
memory scan node memory, reg size 16, data: 0 0 2 0,
- 0 , 2
That
On Sat, Jul 13, 2013 at 12:30:50AM -0600, Chris Friesen wrote:
On 07/12/2013 04:59 PM, Chris Friesen wrote:
On 07/12/2013 03:08 PM, Chris Friesen wrote:
I turned on the instrumentation in early_init_dt_scan_memory() and got
the following when jumping to the capture kernel:
memory scan
On Sun, 2013-07-14 at 14:36 +1000, Michael Ellerman wrote:
Is this expected behaviour? It seems to be the same in current git
versions of kexec-tools.
On my system I see /proc/device-tree/memory.
If I modify add_usable_mem_property() to also accept /memory then
my
This is a bug in
On 07/11/2013 07:21 PM, Michael Ellerman wrote:
On Thu, Jul 11, 2013 at 03:22:49PM -0600, Chris Friesen wrote:
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do
On 07/12/2013 03:08 PM, Chris Friesen wrote:
I turned on the instrumentation in early_init_dt_scan_memory() and got
the following when jumping to the capture kernel:
memory scan node memory, reg size 16, data: 0 0 2 0,
- 0 , 2
That 0x2 matches the fact that I'm seeing 8GB of
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system with 8GB
of memory. (It's an embedded system and I can't do much about the fact that
it's using older software.)
I booted the original kernel with crashkernel=224M@32M in the boot args. I
then loaded the crash kernel
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do much
about the fact that it's using older software.)
I should probably clarify this...I may be able to update
On 07/11/2013 03:22 PM, Chris Friesen wrote:
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do much
about the fact that it's using older software.)
I should
On Thu, Jul 11, 2013 at 03:22:49PM -0600, Chris Friesen wrote:
On 07/11/2013 02:55 PM, Chris Friesen wrote:
Hi,
I'm running 2.6.34 with kexec 2.0.1 on a Freescale p5020-based system
with 8GB of memory. (It's an embedded system and I can't do much
about the fact that it's using older
14 matches
Mail list logo
