On Tue, Oct 04, 2016 at 10:46:27AM +0100, James Morse wrote:

Hi Manish,

On 03/10/16 13:41, Manish Jaggi wrote:

quoted

On 10/03/2016 04:34 PM, AKASHI Takahiro wrote:

quoted

On Mon, Oct 03, 2016 at 01:24:34PM +0530, Manish Jaggi wrote:

quoted

With the v26 kdump and v3 kexec-tools and top of tree crash.git, below are the tests done
Attached is a patch in crash.git (symbols.c) to make crash utility work on my setup.
Can you please have a look and provide your comments.

To generate a panic, i have a kernel module which on init calls panic.

... modules ... I haven't tested that. I bet it causes some problems!
We probably need to include module_alloc_base as an elf note in the vmcore file...

No, I don't think so :)
I created some test module as Manish implied and tested kdump:
(My kernel here even enables KASLR.)
===8<===
$ crash vmlinux vmcore
...
please wait... (gathering module symbol data)
...
crash> mod -S
     MODULE       NAME      SIZE  OBJECT FILE
ffff04d78f4b8000  testmod  16384  /opt/buildroot/15.11_64/root/kexec/testmod.ko 
crash> bt
PID: 1102   TASK: ffffb4da8e910000  CPU: 0   COMMAND: "insmod"
 #0 [ffffb4da8e9afa30] __crash_kexec at ffff0e0045020a54
 #1 [ffffb4da8e9afb90] panic at ffff0e004505523c
 #2 [ffffb4da8e9afc50] testmod_init at ffff04d78f4b6014 [testmod]
 #3 [ffffb4da8e9afb40] do_one_initcall at ffff0e0044f7333c

--- <Exception in user> ---
     PC: 0000000a  LR: 00000000  SP: ffff04d78f4b6000  PSTATE: 7669726420656c75
    X12: ffffb4da8e9ac000 X11: ffff04d78f4b6018 X10: ffffb4da8e9afc50  X9: 20676e6973756143
     X8: 00000000  X7: ffff0e0045e5ce00  X6: ffff0e0045e5c000  X5: 600001c5
     X4: ffff0e0045020a58  X3: ffffb4da8e9afa30  X2: ffff0e004502098c  X1: ffffb4da8e9afa30
     X0: 00000124

crash> disas testmod_init
Dump of assembler code for function testmod_init:
   0xffff04d78f4b6000 <+0>:     stp     x29, x30, [sp,#-16]!
   0xffff04d78f4b6004 <+4>:     mov     x29, sp
   0xffff04d78f4b6008 <+8>:     ldr     x0, 0xffff04d78f4b6018
   0xffff04d78f4b600c <+12>:    bl      0xffff04d78f4b6090
   0xffff04d78f4b6010 <+16>:    ldr     x0, 0xffff04d78f4b6020
   0xffff04d78f4b6014 <+20>:    bl      0xffff04d78f4b6080
End of assembler dump.
===>8===
(I see some issue in disassembled code, though.)

quoted

quoted

quoted

First kernel is booted with mem=2G crashkernel=1G command line option.
While the system has 64G memory.

quoted

quoted

Are you saying that "mem=..." doesn't have any effect?

What I am saying it that If the first kernel is booted using mem= option and crashkernel= option
the memory for second kernel has to be withing the crashkernel size.
As per /proc/iomem System RAM the information is correct, but the /proc/meminfo is showing total memory
much more than the first kernel had in first place.

So your second crashkernel has 63G of memory? Unless you provide the same 'mem='
to the kdump kernel, this is the expected behaviour. The
DT:/reserved-memory/crash_dump describes the memory not to use.

On your first boot with 'mem=2G' memblock_mem_limit_remove_map() called from
arm64_memblock_init() removed the top 62G of memory. Neither the first kernel
nor kexec-tools know about the top 62G.
When you run kexec-tools, it describes what it sees in /proc/iomem in the
DT:/reserved-memory/crash_dump, which is just the remaining 1G of memory.

When we crash and reboot, the crash kernel discovers all 64G of memory from the
EFI memory map.
kexec-tools described the 1G of memory that the first kernel was using in the
DT:/reserved-memory/crash_dump node, so early_init_fdt_scan_reserved_mem()
reserves the 1G of memory the first kernel used. This leaves us with 63G of memory.

Thank you very much for elaborating this on behalf of myself!

This may change with the next version of kdump if it switches back to using
DT:/chosen/linux,usable-memory-range.

Indeed.
We need to talk to Rob.

Thanks,
-Takahiro AKASHI

If you need v26 to avoid the top 62G of memory, you need to provide the same
'mem=' to the first and second kernel.

quoted

quoted

quoted

1.2 Live crash dump fails with error

... do we expect this to work? I don't think it has anything to do with this
series...


Thanks,

James