All of lore.kernel.org
 help / color / mirror / Atom feed
* Help needed with kexec on arm64
       [not found]           ` <CAB5YjtCP6M9=ESJhfxyyYKSGTg8s3Y83qp8RS_oyYkUqcqYcCw@mail.gmail.com>
@ 2016-03-21 10:27             ` Harninder Rai
       [not found]               ` <CAB5YjtCoX5FoRbOYTPCETbbBGmEvs=1Xm6Giho78TH_a7u=eXw@mail.gmail.com>
  2016-04-04 10:49             ` Harninder Rai
  1 sibling, 1 reply; 19+ messages in thread
From: Harninder Rai @ 2016-03-21 10:27 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Takahiro Akashi,

With latest kexec-tools, I have moved little further
Here?s what I get. Is this correct?

kexec -p /run/media/mmcblk0p1/vmlinux --initrd=/run/media/mmcblk0p1/fsl-image-ls2085ardb.ext2.gz
kexec version: 16.03.14.10.05-gef652df-dirty
arch_process_options:112: command_line: (null)
arch_process_options:114: initrd: /run/media/mmcblk0p1/fsl-image-ls2085ardb.ext2.gz
arch_process_options:115: dtb: (null)
arch_process_options:117: port: 0x0
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on /run/media/mmcblk0p1/vmlinux of 65536 bytes failed
kernel: 0xffffa5dfa010 kernel_size: 0x88ece7e
read_1st_dtb: found /sys/firmware/fdt
get_memory_ranges_dt:860: node_13292 memory at 80000000
get_memory_ranges_dt:887:  RAM: 0000000080000000 - 0000000100000000
get_memory_ranges_dt:887:  RAM: 0000008080000000 - 00000083c0000000
get_memory_ranges_dt:901: /sys/firmware/fdt: Success
elf_arm64_load: PE format: yes
p_vaddr: ffff800000080000
dump_crash_ranges: kernel: 000000008c000000 - 000000008fffffff (64 MiB)
dump_crash_ranges: RAM:    0000000080000000 - 000000008bffffff (192 MiB)
dump_crash_ranges: RAM:    0000008080000000 - 00000083bfffffff (13312 MiB)
dump_crash_ranges: RAM:    0000000090000000 - 00000000ffffffff (1792 MiB)
get_crash_notes_per_cpu: crash_notes addr = 83ae9c9200, size = 424
Elf header: p_type = 4, p_offset = 0x83ae9c9200 p_paddr = 0x83ae9c9200 p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 83aea12200, size = 424
Elf header: p_type = 4, p_offset = 0x83aea12200 p_paddr = 0x83aea12200 p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 83aea13200, size = 424
Elf header: p_type = 4, p_offset = 0x83aea13200 p_paddr = 0x83aea13200 p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 83aea14200, size = 424
Elf header: p_type = 4, p_offset = 0x83aea14200 p_paddr = 0x83aea14200 p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 83aea15200, size = 424
Elf header: p_type = 4, p_offset = 0x83aea15200 p_paddr = 0x83aea15200 p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 83aea16200, size = 424
Elf header: p_type = 4, p_offset = 0x83aea16200 p_paddr = 0x83aea16200 p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 83aea17200, size = 424
Elf header: p_type = 4, p_offset = 0x83aea17200 p_paddr = 0x83aea17200 p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
get_crash_notes_per_cpu: crash_notes addr = 83aea18200, size = 424
Elf header: p_type = 4, p_offset = 0x83aea18200 p_paddr = 0x83aea18200 p_vaddr = 0x0 p_filesz = 0x1a8 p_memsz = 0x1a8
vmcoreinfo header: p_type = 4, p_offset = 0x80c0bb90 p_paddr = 0x80c0bb90 p_vaddr = 0x0 p_filesz = 0x1024 p_memsz = 0x1024
phys_to_virt: 0000000080000000 -> ffff800000000000
Elf header: p_type = 1, p_offset = 0x80000000 p_paddr = 0x80000000 p_vaddr = 0xffff800000000000 p_filesz = 0xc000000 p_memsz = 0xc000000
phys_to_virt: 0000008080000000 -> ffff808000000000
Elf header: p_type = 1, p_offset = 0x8080000000 p_paddr = 0x8080000000 p_vaddr = 0xffff808000000000 p_filesz = 0x340000000 p_memsz = 0x340000000
phys_to_virt: 0000000090000000 -> ffff800010000000
Elf header: p_type = 1, p_offset = 0x90000000 p_paddr = 0x90000000 p_vaddr = 0xffff800010000000 p_filesz = 0x70000000 p_memsz = 0x70000000
add_segment_phys_virt: 000000000f82eb30 - 000000000f82ef30 (00000400) -> 000000008ffff000 - 0000000090000000 (00001000)
load_crashdump_segments: elfcorehdr 0x8ffff000-0x8ffff3ff
virt_to_phys: ffff80000c080000 -> 000000008c080000
add_segment_phys_virt: 0000ffffa5e0a010 - 0000ffffa6983810 (00b79800) -> 000000008c080000 - 000000008cc3b000 (00bbb000)
elf_arm64_load: text_offset: 0000000000080000
elf_arm64_load: image_size:  0000000000bc1000
elf_arm64_load: page_offset: ffff800000000000
elf_arm64_load: memstart:    0000000080000000
virt_to_phys: ffff80008c080000 -> 000000010c080000
elf_arm64_load: e_entry:     ffff80008c080000 -> 000000010c080000
elf_arm64_load: kernel_entry:000000008c080000
arm64_load_other_segments:665: purgatory sink: 0x0
read_1st_dtb: found /sys/firmware/fdt
dump_reservemap: dtb_1 {80000000, 10000}
dump_reservemap: dtb_1 {fff0e590, 578}
dump_reservemap: dtb_1 {9fff9000, 4000}
dump_reservemap: dtb_1 {a0515e2c, 1a64530}
read_cpu_info: dtb_1 cpu-0 (/cpus/cpu at 0): hwid-0, 'spin-table', cpu-release-addr fff0e590
read_cpu_info: dtb_1 cpu-1 (/cpus/cpu at 1): hwid-1, 'spin-table', cpu-release-addr fff0e5d0
read_cpu_info: dtb_1 cpu-2 (/cpus/cpu at 100): hwid-100, 'spin-table', cpu-release-addr fff0e690
read_cpu_info: dtb_1 cpu-3 (/cpus/cpu at 101): hwid-101, 'spin-table', cpu-release-addr fff0e6d0
read_cpu_info: dtb_1 cpu-4 (/cpus/cpu at 200): hwid-200, 'spin-table', cpu-release-addr fff0e790
read_cpu_info: dtb_1 cpu-5 (/cpus/cpu at 201): hwid-201, 'spin-table', cpu-release-addr fff0e7d0
read_cpu_info: dtb_1 cpu-6 (/cpus/cpu at 300): hwid-300, 'spin-table', cpu-release-addr fff0e890
read_cpu_info: dtb_1 cpu-7 (/cpus/cpu at 301): hwid-301, 'spin-table', cpu-release-addr fff0e8d0
read_cpu_info: dtb_1 cpu-0 (/cpus/cpu at 0): hwid-0, 'spin-table', cpu-release-addr fff0e590
read_cpu_info: dtb_1 cpu-1 (/cpus/cpu at 1): hwid-1, 'spin-table', cpu-release-addr fff0e5d0
read_cpu_info: dtb_1 cpu-2 (/cpus/cpu at 100): hwid-100, 'spin-table', cpu-release-addr fff0e690
read_cpu_info: dtb_1 cpu-3 (/cpus/cpu at 101): hwid-101, 'spin-table', cpu-release-addr fff0e6d0
read_cpu_info: dtb_1 cpu-4 (/cpus/cpu at 200): hwid-200, 'spin-table', cpu-release-addr fff0e790
read_cpu_info: dtb_1 cpu-5 (/cpus/cpu at 201): hwid-201, 'spin-table', cpu-release-addr fff0e7d0
read_cpu_info: dtb_1 cpu-6 (/cpus/cpu at 300): hwid-300, 'spin-table', cpu-release-addr fff0e890
read_cpu_info: dtb_1 cpu-7 (/cpus/cpu at 301): hwid-301, 'spin-table', cpu-release-addr fff0e8d0
check_cpu_properties: hwid-0: OK
check_cpu_properties: hwid-1: OK
check_cpu_properties: hwid-100: OK
check_cpu_properties: hwid-101: OK
check_cpu_properties: hwid-200: OK
check_cpu_properties: hwid-201: OK
check_cpu_properties: hwid-300: OK
check_cpu_properties: hwid-301: OK
add_segment_phys_virt: 0000ffffa429b010 - 0000ffffa5df9fe5 (01b5efd5) -> 000000008cc41000 - 000000008e7a0000 (01b5f000)
initrd: base 8cc41000, size 1b5efd5h (28700629)
dtb_set_initrd: start 2361659392, end 2390360021, size 28700629 (28027 KiB)
add_segment_phys_virt: 000000000f83b1e0 - 000000000f83f32c (0000414c) -> 000000008e7a0000 - 000000008e7a5000 (00005000)
dtb:    base 8e7a0000, size 414ch (16716)
add_segment_phys_virt: 000000000f83f6f0 - 000000000f842b50 (00003460) -> 000000008e7a5000 - 000000008e7a9000 (00004000)
sym: sha256_starts info: 12 other: 00 shndx: 1 value: f60 size: 6c
sym: sha256_starts value: 8e7a5f60 addr: 8e7a5018
machine_apply_elf_rel: CALL26 580006b394000000->580006b3940003d2
sym: sha256_update info: 12 other: 00 shndx: 1 value: 3064 size: c
sym: sha256_update value: 8e7a8064 addr: 8e7a5034
machine_apply_elf_rel: CALL26 eb15027f94000000->eb15027f94000c0c
sym: sha256_finish info: 12 other: 00 shndx: 1 value: 3070 size: 1c8
sym: sha256_finish value: 8e7a8070 addr: 8e7a504c
machine_apply_elf_rel: CALL26 d280040294000000->d280040294000c09
sym:     memcmp info: 12 other: 00 shndx: 1 value: 64c size: 34
sym: memcmp value: 8e7a564c addr: 8e7a505c
machine_apply_elf_rel: CALL26 340003c094000000->340003c09400017c
sym:     printf info: 12 other: 00 shndx: 1 value: 554 size: 90
sym: printf value: 8e7a5554 addr: 8e7a506c
machine_apply_elf_rel: CALL26 5800048094000000->580004809400013a
sym:     printf info: 12 other: 00 shndx: 1 value: 554 size: 90
sym: printf value: 8e7a5554 addr: 8e7a5074
machine_apply_elf_rel: CALL26 5800049594000000->5800049594000138
sym:     printf info: 12 other: 00 shndx: 1 value: 554 size: 90
sym: printf value: 8e7a5554 addr: 8e7a508c
machine_apply_elf_rel: CALL26 f100827f94000000->f100827f94000132
sym:     printf info: 12 other: 00 shndx: 1 value: 554 size: 90
sym: printf value: 8e7a5554 addr: 8e7a50a4
machine_apply_elf_rel: CALL26 5800038094000000->580003809400012c
sym:     printf info: 12 other: 00 shndx: 1 value: 554 size: 90
sym: printf value: 8e7a5554 addr: 8e7a50ac
machine_apply_elf_rel: CALL26 910402c094000000->910402c09400012a
sym:     printf info: 12 other: 00 shndx: 1 value: 554 size: 90
sym: printf value: 8e7a5554 addr: 8e7a50c0
machine_apply_elf_rel: CALL26 f100829f94000000->f100829f94000125
sym:     printf info: 12 other: 00 shndx: 1 value: 554 size: 90
sym: printf value: 8e7a5554 addr: 8e7a50d0
machine_apply_elf_rel: CALL26 5280002094000000->5280002094000121
sym:      .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 8e7a82d8 addr: 8e7a50f0
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a82d8
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8e7a8240 addr: 8e7a50f8
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8240
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8e7a8260 addr: 8e7a5100
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8260
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8e7a8270 addr: 8e7a5108
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8270
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8e7a8276 addr: 8e7a5110
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8276
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8e7a8278 addr: 8e7a5118
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8278
sym:     printf info: 12 other: 00 shndx: 1 value: 554 size: 90
sym: printf value: 8e7a5554 addr: 8e7a512c
machine_apply_elf_rel: CALL26 9400000094000000->940000009400010a
sym: setup_arch info: 12 other: 00 shndx: 1 value: f10 size: 2c
sym: setup_arch value: 8e7a5f10 addr: 8e7a5130
machine_apply_elf_rel: CALL26 5800016094000000->5800016094000378
sym: verify_sha256_digest info: 12 other: 00 shndx: 1 value: 0 size: ec
sym: verify_sha256_digest value: 8e7a5000 addr: 8e7a5140
machine_apply_elf_rel: CALL26 3400004094000000->3400004097ffffb0
sym: post_verification_setup_arch info: 12 other: 00 shndx: 1 value: ee0 size: 20
sym: post_verification_setup_arch value: 8e7a5ee0 addr: 8e7a5150
machine_apply_elf_rel: JUMP26 d503201f14000000->d503201f14000364
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8e7a8288 addr: 8e7a5158
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8288
sym:      .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 8e7a82d8 addr: 8e7a5160
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a82d8
sym:    putchar info: 12 other: 00 shndx: 1 value: ea0 size: 34
sym: putchar value: 8e7a5ea0 addr: 8e7a51c4
machine_apply_elf_rel: CALL26 140000b494000000->140000b494000337
sym:    putchar info: 12 other: 00 shndx: 1 value: ea0 size: 34
sym: putchar value: 8e7a5ea0 addr: 8e7a5234
machine_apply_elf_rel: CALL26 9100069494000000->910006949400031b
sym:    putchar info: 12 other: 00 shndx: 1 value: ea0 size: 34
sym: putchar value: 8e7a5ea0 addr: 8e7a5488
machine_apply_elf_rel: CALL26 9100071894000000->9100071894000286
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8e7a829a addr: 8e7a54c8
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a829a
sym:   vsprintf info: 12 other: 00 shndx: 1 value: 168 size: 35c
sym: vsprintf value: 8e7a5168 addr: 8e7a5548
machine_apply_elf_rel: CALL26 a8d07bfd94000000->a8d07bfd97ffff08
sym:   vsprintf info: 12 other: 00 shndx: 1 value: 168 size: 35c
sym: vsprintf value: 8e7a5168 addr: 8e7a55d8
machine_apply_elf_rel: CALL26 a8d17bfd94000000->a8d17bfd97fffee4
sym:  purgatory info: 12 other: 00 shndx: 1 value: 120 size: 34
sym: purgatory value: 8e7a5120 addr: 8e7a5688
machine_apply_elf_rel: CALL26 d280030094000000->d280030097fffea6
sym: arm64_sink info: 10 other: 00 shndx: 4 value: 128 size: 8
sym: arm64_sink value: 8e7a8400 addr: 8e7a5ed8
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8400
sym: arm64_kernel_entry info: 10 other: 00 shndx: 4 value: 130 size: 8
sym: arm64_kernel_entry value: 8e7a8408 addr: 8e7a5f00
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8408
sym: arm64_dtb_addr info: 10 other: 00 shndx: 4 value: 138 size: 8
sym: arm64_dtb_addr value: 8e7a8410 addr: 8e7a5f08
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8410
sym:     printf info: 12 other: 00 shndx: 1 value: 554 size: 90
sym: printf value: 8e7a5554 addr: 8e7a5f24
machine_apply_elf_rel: CALL26 5800014094000000->5800014097fffd8c
sym:     printf info: 12 other: 00 shndx: 1 value: 554 size: 90
sym: printf value: 8e7a5554 addr: 8e7a5f38
machine_apply_elf_rel: JUMP26 d503201f14000000->d503201f17fffd87
sym: arm64_kernel_entry info: 10 other: 00 shndx: 4 value: 130 size: 8
sym: arm64_kernel_entry value: 8e7a8408 addr: 8e7a5f40
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8408
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8e7a82ab addr: 8e7a5f48
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a82ab
sym: arm64_dtb_addr info: 10 other: 00 shndx: 4 value: 138 size: 8
sym: arm64_dtb_addr value: 8e7a8410 addr: 8e7a5f50
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8410
sym: .rodata.str1.1 info: 03 other: 00 shndx: 3 value: 0 size: 0
sym: .rodata.str1.1 value: 8e7a82c1 addr: 8e7a5f58
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a82c1
sym: sha256_process info: 12 other: 00 shndx: 1 value: fcc size: 1f94
sym: sha256_process value: 8e7a5fcc addr: 8e7a7fd8
machine_apply_elf_rel: CALL26 f100fe9f94000000->f100fe9f97fff7fd
sym:     memcpy info: 12 other: 00 shndx: 1 value: 62c size: 20
sym: memcpy value: 8e7a562c addr: 8e7a8028
machine_apply_elf_rel: CALL26 9100c2a194000000->9100c2a197fff581
sym: sha256_process info: 12 other: 00 shndx: 1 value: fcc size: 1f94
sym: sha256_process value: 8e7a5fcc addr: 8e7a8034
machine_apply_elf_rel: CALL26 17ffffe094000000->17ffffe097fff7e6
sym:     memcpy info: 12 other: 00 shndx: 1 value: 62c size: 20
sym: memcpy value: 8e7a562c addr: 8e7a8058
machine_apply_elf_rel: JUMP26 aa1603e214000000->aa1603e217fff575
sym:      .data info: 03 other: 00 shndx: 4 value: 0 size: 0
sym: .data value: 8e7a8420 addr: 8e7a8238
machine_apply_elf_rel: ABS64 0000000000000000->000000008e7a8420
kexec_load: entry = 0x8e7a5680 flags = 0xb70001
nr_segments = 5
segment[0].buf   = 0xffffa5e0a010
segment[0].bufsz = 0xb79800
segment[0].mem   = 0x8c080000
segment[0].memsz = 0xbbb000
segment[1].buf   = 0xffffa429b010
segment[1].bufsz = 0x1b5efd5
segment[1].mem   = 0x8cc41000
segment[1].memsz = 0x1b5f000
segment[2].buf   = 0xf83b1e0
segment[2].bufsz = 0x414c
segment[2].mem   = 0x8e7a0000
segment[2].memsz = 0x5000
segment[3].buf   = 0xf83f6f0
segment[3].bufsz = 0x3460
segment[3].mem   = 0x8e7a5000
segment[3].memsz = 0x4000
segment[4].buf   = 0xf82eb30
segment[4].bufsz = 0x400
segment[4].mem   = 0x8ffff000
segment[4].memsz = 0x1000



And I do get a kernel panic when I try to dump the image of panicked kernel (using /proc/sysrq-trigger)


Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.5.0-rc6-00038-gae2804a-dirty (hrai at nmglablinux22) (gcc version 4.8.3 20140401 (prerelease) (Linaro GCC 4.8-2014.04) ) #2 SMP PREEMPT Fri Mar 11 14:45:30 IST 2016
[    0.000000] Boot CPU: AArch64 Processor [411fd071]
[    0.000000] Ignoring memory range 0x80000000 - 0x8c000000
[    0.000000] earlycon: Early serial console at MMIO 0x21c0600 (options '')
[    0.000000] bootconsole [uart0] enabled
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] crashkernel has wrong address or size
[    0.000000] Reserving 1KB of memory at 0x8ffff000 for elfcorehdr
[    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 0000000080000000, 0000000000010000
[    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 00000000fff0e590, 0000000000000578
[    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 000000009fff9000, 0000000000004000
[    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 00000000a0515e2c, 0000000001a64530
[    0.000000] cma: Reserved 16 MiB at 0x000000008ec00000
[    0.000000] Kernel panic - not syncing: memblock_virt_alloc_try_nid: Failed to allocate 2097152 bytes align=0x200000 nid=0 from=0x8c000000 max_addr=0x0
[    0.000000]
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.5.0-rc6-00038-gae2804a-dirty #2
[    0.000000] Hardware name: Freescale Layerscape 2085a RDB Board (DT)
[    0.000000] Call trace:
[    0.000000] [<ffff800000089760>] dump_backtrace+0x0/0x1ac
[    0.000000] [<ffff800000089920>] show_stack+0x14/0x1c
[    0.000000] [<ffff80000032c1d4>] dump_stack+0x8c/0xb0
[    0.000000] [<ffff80000014c420>] panic+0x120/0x288
[    0.000000] [<ffff800000ab01a0>] memblock_virt_alloc_try

Thanks and Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
       [not found]               ` <CAB5YjtCoX5FoRbOYTPCETbbBGmEvs=1Xm6Giho78TH_a7u=eXw@mail.gmail.com>
@ 2016-03-22 17:49                 ` Harninder Rai
  0 siblings, 0 replies; 19+ messages in thread
From: Harninder Rai @ 2016-03-22 17:49 UTC (permalink / raw)
  To: linux-arm-kernel

>
> Booting Linux on physical CPU 0x0
> [ ? ?0.000000] Linux version 4.5.0-rc6-00038-gae2804a-dirty (hrai at nmglablinux22) (gcc version 4.8.3 20140401 (prerelease) (Linaro GCC 4.8-2014.04) ) #2 SMP PREEMPT Fri Mar 11 14:45:30 IST 2016
> [ ? ?0.000000] Boot CPU: AArch64 Processor [411fd071]
> [ ? ?0.000000] Ignoring memory range 0x80000000 - 0x8c000000
> [ ? ?0.000000] earlycon: Early serial console at MMIO 0x21c0600 (options '')
> [ ? ?0.000000] bootconsole [uart0] enabled
> [ ? ?0.000000] efi: Getting EFI parameters from FDT:
> [ ? ?0.000000] efi: UEFI not found.
> [ ? ?0.000000] crashkernel has wrong address or size
This implies a root cause. (See arch/arm64/mm/init.c)
Hint: add memblock=debug to kernel parameters of crash dump kernel

Thanks for the hint. I will try this out
One thing which comes to my mind is that I am using the production kernel image for crash kernel and Documentation/kdump doesn't mention that arm64 supports that. Can this be a cause for the above problem?

Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
       [not found]           ` <CAB5YjtCP6M9=ESJhfxyyYKSGTg8s3Y83qp8RS_oyYkUqcqYcCw@mail.gmail.com>
  2016-03-21 10:27             ` Help needed with kexec on arm64 Harninder Rai
@ 2016-04-04 10:49             ` Harninder Rai
  2016-04-05  5:23               ` AKASHI Takahiro
  1 sibling, 1 reply; 19+ messages in thread
From: Harninder Rai @ 2016-04-04 10:49 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Takahiro Akashi/Geoff,

With memblock option added to bootargs, I get the following
Any pointers as to what could be going wrong here?

[    0.000000] Linux version 4.5.0-rc6-00038-gae2804a-dirty (hrai at nmglablinux22) (gcc version 4.8.3 20140401 (prerelease) (Linaro GCC 4.8-2014.04) ) #2 SMP PREEMPT Fri Mar 11 14:45:30 IST 2016
[    0.000000] Boot CPU: AArch64 Processor [411fd071]
[    0.000000] Ignoring memory range 0x80000000 - 0x8c000000
[    0.000000] earlycon: Early serial console at MMIO 0x21c0600 (options '')
[    0.000000] bootconsole [uart0] enabled
[    0.000000] efi: Getting EFI parameters from FDT:
[    0.000000] efi: UEFI not found.
[    0.000000] memblock_reserve: [0x0000008c080000-0x0000008cc40fff] flags 0x0 arm64_memblock_init+0x98/0x26c
[    0.000000] memblock_reserve: [0x0000008cc41000-0x0000008e79ffd4] flags 0x0 arm64_memblock_init+0xc0/0x26c
[    0.000000] memblock_reserve: [0x0000008ffff000-0x0000008ffff3ff] flags 0x0 arm64_memblock_init+0x1f8/0x26c
[    0.000000] Reserving 1KB of memory at 0x8ffff000 for elfcorehdr
[    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 0000000080000000, 0000000000010000
[    0.000000] memblock_reserve: [0x00000080000000-0x0000008000ffff] flags 0x0 early_init_dt_reserve_memory_arch+0x1c/0x24
[    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 00000000fff09e90, 0000000000000578
[    0.000000] memblock_reserve: [0x000000fff09e90-0x000000fff0a407] flags 0x0 early_init_dt_reserve_memory_arch+0x1c/0x24
[    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 000000009fff9000, 0000000000004000
[    0.000000] memblock_reserve: [0x0000009fff9000-0x0000009fffcfff] flags 0x0 early_init_dt_reserve_memory_arch+0x1c/0x24
[    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 00000000a0515e2c, 0000000001a64530
[    0.000000] memblock_reserve: [0x000000a0515e2c-0x000000a1f7a35b] flags 0x0 early_init_dt_reserve_memory_arch+0x1c/0x24
[    0.000000] memblock_reserve: [0x0000008ec00000-0x0000008fbfffff] flags 0x0 memblock_alloc_range_nid+0x64/0x78
[    0.000000] cma: Reserved 16 MiB at 0x000000008ec00000
[    0.000000] MEMBLOCK configuration:
[    0.000000]  memory size = 0x4000000 reserved size = 0x519d181
[    0.000000]  memory.cnt  = 0x1
[    0.000000]  memory[0x0]     [0x0000008c000000-0x0000008fffffff], 0x4000000 bytes flags: 0x0
[    0.000000]  reserved.cnt  = 0x8
[    0.000000]  reserved[0x0]   [0x00000080000000-0x0000008000ffff], 0x10000 bytes flags: 0x0
[    0.000000]  reserved[0x1]   [0x0000008c080000-0x0000008e79ffd4], 0x271ffd5 bytes flags: 0x0
[    0.000000]  reserved[0x2]   [0x0000008e7a0000-0x0000008e7a4303], 0x4304 bytes flags: 0x0
[    0.000000]  reserved[0x3]   [0x0000008ec00000-0x0000008fbfffff], 0x1000000 bytes flags: 0x0
[    0.000000]  reserved[0x4]   [0x0000008ffff000-0x0000008ffff3ff], 0x400 bytes flags: 0x0
[    0.000000]  reserved[0x5]   [0x0000009fff9000-0x0000009fffcfff], 0x4000 bytes flags: 0x0
[    0.000000]  reserved[0x6]   [0x000000a0515e2c-0x000000a1f7a35b], 0x1a64530 bytes flags: 0x0
[    0.000000]  reserved[0x7]   [0x000000fff09e90-0x000000fff0a407], 0x578 bytes flags: 0x0
[    0.000000] memblock_reserve: [0x0000008fffe000-0x0000008fffefff] flags 0x0 memblock_alloc_range_nid+0x64/0x78
[    0.000000] memblock_virt_alloc_try_nid: 4096 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 sparse_index_alloc+0x4c/0x58
[    0.000000] memblock_reserve: [0x0000008fffd000-0x0000008fffdfff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
[    0.000000] memblock_virt_alloc_try_nid: 2097152 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 sparse_init+0x38/0x1f4
[    0.000000] memblock_reserve: [0x0000008fdfd000-0x0000008fffcfff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
[    0.000000] memblock_virt_alloc_try_nid_nopanic: 256 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 sparse_early_usemaps_alloc_node+0x38/0xac
[    0.000000] memblock_reserve: [0x0000008fffff00-0x0000008fffffff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
[    0.000000] memblock_virt_alloc_try_nid: 4096 bytes align=0x1000 nid=0 from=0x8c000000 max_addr=0x0 __earlyonly_bootmem_alloc+0x20/0x28
[    0.000000] memblock_reserve: [0x0000008fdfc000-0x0000008fdfcfff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
[    0.000000] memblock_virt_alloc_try_nid: 4096 bytes align=0x1000 nid=0 from=0x8c000000 max_addr=0x0 __earlyonly_bootmem_alloc+0x20/0x28
[    0.000000] memblock_reserve: [0x0000008fdfb000-0x0000008fdfbfff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
[    0.000000] memblock_virt_alloc_try_nid: 2097152 bytes align=0x200000 nid=0 from=0x8c000000 max_addr=0x0 __earlyonly_bootmem_alloc+0x20/0x28
[    0.000000] memblock_reserve: [0x0000008ea00000-0x0000008ebfffff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
[    0.000000] memblock_virt_alloc_try_nid: 2097152 bytes align=0x200000 nid=0 from=0x8c000000 max_addr=0x0 __earlyonly_bootmem_alloc+0x20/0x28
[    0.000000] memblock_reserve: [0x0000008e800000-0x0000008e9fffff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
[    0.000000] memblock_virt_alloc_try_nid: 2097152 bytes align=0x200000 nid=0 from=0x8c000000 max_addr=0x0 __earlyonly_bootmem_alloc+0x20/0x28
[    0.000000] Kernel panic - not syncing: memblock_virt_alloc_try_nid: Failed to allocate 2097152 bytes align=0x200000 nid=0 from=0x8c000000 max_addr=0x0

Thanks and Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-04-04 10:49             ` Harninder Rai
@ 2016-04-05  5:23               ` AKASHI Takahiro
  2016-04-05 10:42                 ` Harninder Rai
                                   ` (2 more replies)
  0 siblings, 3 replies; 19+ messages in thread
From: AKASHI Takahiro @ 2016-04-05  5:23 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Apr 04, 2016 at 10:49:01AM +0000, Harninder Rai wrote:
> Hello Takahiro Akashi/Geoff,
> 
> With memblock option added to bootargs, I get the following
> Any pointers as to what could be going wrong here?
> 
> [    0.000000] Linux version 4.5.0-rc6-00038-gae2804a-dirty (hrai at nmglablinux22) (gcc version 4.8.3 20140401 (prerelease) (Linaro GCC 4.8-2014.04) ) #2 SMP PREEMPT Fri Mar 11 14:45:30 IST 2016
> [    0.000000] Boot CPU: AArch64 Processor [411fd071]
> [    0.000000] Ignoring memory range 0x80000000 - 0x8c000000
> [    0.000000] earlycon: Early serial console at MMIO 0x21c0600 (options '')
> [    0.000000] bootconsole [uart0] enabled
> [    0.000000] efi: Getting EFI parameters from FDT:
> [    0.000000] efi: UEFI not found.
> [    0.000000] memblock_reserve: [0x0000008c080000-0x0000008cc40fff] flags 0x0 arm64_memblock_init+0x98/0x26c
> [    0.000000] memblock_reserve: [0x0000008cc41000-0x0000008e79ffd4] flags 0x0 arm64_memblock_init+0xc0/0x26c
> [    0.000000] memblock_reserve: [0x0000008ffff000-0x0000008ffff3ff] flags 0x0 arm64_memblock_init+0x1f8/0x26c
> [    0.000000] Reserving 1KB of memory at 0x8ffff000 for elfcorehdr
> [    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 0000000080000000, 0000000000010000
> [    0.000000] memblock_reserve: [0x00000080000000-0x0000008000ffff] flags 0x0 early_init_dt_reserve_memory_arch+0x1c/0x24
> [    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 00000000fff09e90, 0000000000000578
> [    0.000000] memblock_reserve: [0x000000fff09e90-0x000000fff0a407] flags 0x0 early_init_dt_reserve_memory_arch+0x1c/0x24
> [    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 000000009fff9000, 0000000000004000
> [    0.000000] memblock_reserve: [0x0000009fff9000-0x0000009fffcfff] flags 0x0 early_init_dt_reserve_memory_arch+0x1c/0x24
> [    0.000000] early_init_fdt_scan_reserved_mem: ERROR: /memreserve/ field not compatible with kexec: 00000000a0515e2c, 0000000001a64530
> [    0.000000] memblock_reserve: [0x000000a0515e2c-0x000000a1f7a35b] flags 0x0 early_init_dt_reserve_memory_arch+0x1c/0x24
> [    0.000000] memblock_reserve: [0x0000008ec00000-0x0000008fbfffff] flags 0x0 memblock_alloc_range_nid+0x64/0x78
> [    0.000000] cma: Reserved 16 MiB at 0x000000008ec00000
> [    0.000000] MEMBLOCK configuration:
> [    0.000000]  memory size = 0x4000000 reserved size = 0x519d181
> [    0.000000]  memory.cnt  = 0x1
> [    0.000000]  memory[0x0]     [0x0000008c000000-0x0000008fffffff], 0x4000000 bytes flags: 0x0
> [    0.000000]  reserved.cnt  = 0x8
> [    0.000000]  reserved[0x0]   [0x00000080000000-0x0000008000ffff], 0x10000 bytes flags: 0x0
> [    0.000000]  reserved[0x1]   [0x0000008c080000-0x0000008e79ffd4], 0x271ffd5 bytes flags: 0x0
> [    0.000000]  reserved[0x2]   [0x0000008e7a0000-0x0000008e7a4303], 0x4304 bytes flags: 0x0
> [    0.000000]  reserved[0x3]   [0x0000008ec00000-0x0000008fbfffff], 0x1000000 bytes flags: 0x0
> [    0.000000]  reserved[0x4]   [0x0000008ffff000-0x0000008ffff3ff], 0x400 bytes flags: 0x0
> [    0.000000]  reserved[0x5]   [0x0000009fff9000-0x0000009fffcfff], 0x4000 bytes flags: 0x0
> [    0.000000]  reserved[0x6]   [0x000000a0515e2c-0x000000a1f7a35b], 0x1a64530 bytes flags: 0x0
> [    0.000000]  reserved[0x7]   [0x000000fff09e90-0x000000fff0a407], 0x578 bytes flags: 0x0
> [    0.000000] memblock_reserve: [0x0000008fffe000-0x0000008fffefff] flags 0x0 memblock_alloc_range_nid+0x64/0x78
> [    0.000000] memblock_virt_alloc_try_nid: 4096 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 sparse_index_alloc+0x4c/0x58
> [    0.000000] memblock_reserve: [0x0000008fffd000-0x0000008fffdfff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
> [    0.000000] memblock_virt_alloc_try_nid: 2097152 bytes align=0x0 nid=-1 from=0x0 max_addr=0x0 sparse_init+0x38/0x1f4
> [    0.000000] memblock_reserve: [0x0000008fdfd000-0x0000008fffcfff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
> [    0.000000] memblock_virt_alloc_try_nid_nopanic: 256 bytes align=0x0 nid=0 from=0x0 max_addr=0x0 sparse_early_usemaps_alloc_node+0x38/0xac
> [    0.000000] memblock_reserve: [0x0000008fffff00-0x0000008fffffff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
> [    0.000000] memblock_virt_alloc_try_nid: 4096 bytes align=0x1000 nid=0 from=0x8c000000 max_addr=0x0 __earlyonly_bootmem_alloc+0x20/0x28
> [    0.000000] memblock_reserve: [0x0000008fdfc000-0x0000008fdfcfff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
> [    0.000000] memblock_virt_alloc_try_nid: 4096 bytes align=0x1000 nid=0 from=0x8c000000 max_addr=0x0 __earlyonly_bootmem_alloc+0x20/0x28
> [    0.000000] memblock_reserve: [0x0000008fdfb000-0x0000008fdfbfff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
> [    0.000000] memblock_virt_alloc_try_nid: 2097152 bytes align=0x200000 nid=0 from=0x8c000000 max_addr=0x0 __earlyonly_bootmem_alloc+0x20/0x28
> [    0.000000] memblock_reserve: [0x0000008ea00000-0x0000008ebfffff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
> [    0.000000] memblock_virt_alloc_try_nid: 2097152 bytes align=0x200000 nid=0 from=0x8c000000 max_addr=0x0 __earlyonly_bootmem_alloc+0x20/0x28
> [    0.000000] memblock_reserve: [0x0000008e800000-0x0000008e9fffff] flags 0x0 memblock_virt_alloc_internal+0x18c/0x1e4
> [    0.000000] memblock_virt_alloc_try_nid: 2097152 bytes align=0x200000 nid=0 from=0x8c000000 max_addr=0x0 __earlyonly_bootmem_alloc+0x20/0x28
> [    0.000000] Kernel panic - not syncing: memblock_virt_alloc_try_nid: Failed to allocate 2097152 bytes align=0x200000 nid=0 from=0x8c000000 max_addr=0x0

This means that there is no enough space left at this point.
I guess that you are using too big initramfs against 64MB of total memory.
Just increase the memory size for crash dump kernel.

-Takahiro AKASHI

> 
> Thanks and Regards
> Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-04-05  5:23               ` AKASHI Takahiro
@ 2016-04-05 10:42                 ` Harninder Rai
  2016-05-10 12:32                 ` Harninder Rai
  2016-05-19 10:48                 ` Harninder Rai
  2 siblings, 0 replies; 19+ messages in thread
From: Harninder Rai @ 2016-04-05 10:42 UTC (permalink / raw)
  To: linux-arm-kernel

> This means that there is no enough space left at this point.
> I guess that you are using too big initramfs against 64MB of total memory.
> Just increase the memory size for crash dump kernel.

Thanks Takahiro. Let me try either with small initramfs or increase memory size for crash dump kernel


Thanks and Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-04-05  5:23               ` AKASHI Takahiro
  2016-04-05 10:42                 ` Harninder Rai
@ 2016-05-10 12:32                 ` Harninder Rai
  2016-05-11  0:53                   ` AKASHI Takahiro
  2016-05-19 10:48                 ` Harninder Rai
  2 siblings, 1 reply; 19+ messages in thread
From: Harninder Rai @ 2016-05-10 12:32 UTC (permalink / raw)
  To: linux-arm-kernel

> 
> This means that there is no enough space left at this point.
> I guess that you are using too big initramfs against 64MB of total memory.
> Just increase the memory size for crash dump kernel.
> 
> -Takahiro AKASHI

Hello Takahiro Akashi,

I used a smaller initramfs (as you suggested) and my crash kernel has moved further but it again dumped with the following log messages. Any further pointers?
Does this mean that there isn't enough memory to save the core file or something? Because the error mostly are related to OOM killer process

[    8.833434] Freeing unused kernel memory: 748K (ffff800000a3a000 - ffff800000af5000)
[    8.848924] init: Console is alive
[    8.856866] mmc0: new high speed SDHC card at address b368
[    8.868239] mmcblk0: mmc0:b368 SDC   3.75 GiB
[    8.873913]  mmcblk0: p1
[    9.855930] init: - preinit -
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[   12.896779] procd: - early -
[   12.977417] kworker/u16:0 invoked oom-killer: gfp_mask=0x27000c0, order=2, oom_score_adj=0
[   12.994568] CPU: 0 PID: 6 Comm: kworker/u16:0 Not tainted 4.5.0-rc6-00038-gae2804a-dirty #5
[   13.002950] Hardware name: Freescale Layerscape 2085a RDB Board (DT)
[   13.009333] Workqueue: events_unbound call_usermodehelper_exec_work
[   13.015623] Call trace:
[   13.018076] [<ffff800000089760>] dump_backtrace+0x0/0x1ac
[   13.023492] [<ffff800000089920>] show_stack+0x14/0x1c
[   13.028560] [<ffff80000032c1d4>] dump_stack+0x8c/0xb0
[   13.033627] [<ffff8000001aebdc>] dump_header.isra.7+0x4c/0x18c
[   13.039480] [<ffff800000152130>] oom_kill_process+0x26c/0x45c
[   13.045243] [<ffff800000152688>] out_of_memory+0x2e0/0x32c
[   13.050745] [<ffff800000156c68>] __alloc_pages_nodemask+0x83c/0x848
[   13.057031] [<ffff800000156f78>] alloc_kmem_pages_node+0x30/0xa8
[   13.063058] [<ffff8000000b776c>] copy_process.isra.42.part.43+0x128/0x1488
[   13.069955] [<ffff8000000b8c4c>] _do_fork+0xcc/0x338
[   13.074934] [<ffff8000000b8f04>] kernel_thread+0x34/0x3c
[   13.080261] [<ffff8000000cb8e0>] call_usermodehelper_exec_work+0x2c/0xd8
[   13.086984] [<ffff8000000ce4b0>] process_one_work+0x134/0x2f4
[   13.092747] [<ffff8000000ce6c8>] worker_thread+0x58/0x43c
[   13.098162] [<ffff8000000d3f88>] kthread+0xd8/0xec
[   13.102967] [<ffff800000085cd0>] ret_from_fork+0x10/0x40
[   13.261745] Mem-Info:

Thanks and Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-10 12:32                 ` Harninder Rai
@ 2016-05-11  0:53                   ` AKASHI Takahiro
  2016-05-11 11:06                     ` Harninder Rai
  2016-05-13 12:45                     ` Harninder Rai
  0 siblings, 2 replies; 19+ messages in thread
From: AKASHI Takahiro @ 2016-05-11  0:53 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Tue, May 10, 2016 at 12:32:15PM +0000, Harninder Rai wrote:
> > 
> > This means that there is no enough space left at this point.
> > I guess that you are using too big initramfs against 64MB of total memory.
> > Just increase the memory size for crash dump kernel.
> > 
> > -Takahiro AKASHI
> 
> Hello Takahiro Akashi,
> 
> I used a smaller initramfs (as you suggested) and my crash kernel has moved further but it again dumped with the following log messages. Any further pointers?

It seems that you have already reached the point of kicking up "init"
process, and this means that crash dump kernel itself successfully
booted.

> Does this mean that there isn't enough memory to save the core file or something? Because the error mostly are related to OOM killer process

Apparently lack of memory is a cause of OOM killer, but the core file
has nothing to do with this issue.
I think that you don't have enough memory for the system yet.

-Takahiro AKASHI

> 
> [    8.833434] Freeing unused kernel memory: 748K (ffff800000a3a000 - ffff800000af5000)
> [    8.848924] init: Console is alive
> [    8.856866] mmc0: new high speed SDHC card at address b368
> [    8.868239] mmcblk0: mmc0:b368 SDC   3.75 GiB
> [    8.873913]  mmcblk0: p1
> [    9.855930] init: - preinit -
> Press the [f] key and hit [enter] to enter failsafe mode
> Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
> [   12.896779] procd: - early -
> [   12.977417] kworker/u16:0 invoked oom-killer: gfp_mask=0x27000c0, order=2, oom_score_adj=0
> [   12.994568] CPU: 0 PID: 6 Comm: kworker/u16:0 Not tainted 4.5.0-rc6-00038-gae2804a-dirty #5
> [   13.002950] Hardware name: Freescale Layerscape 2085a RDB Board (DT)
> [   13.009333] Workqueue: events_unbound call_usermodehelper_exec_work
> [   13.015623] Call trace:
> [   13.018076] [<ffff800000089760>] dump_backtrace+0x0/0x1ac
> [   13.023492] [<ffff800000089920>] show_stack+0x14/0x1c
> [   13.028560] [<ffff80000032c1d4>] dump_stack+0x8c/0xb0
> [   13.033627] [<ffff8000001aebdc>] dump_header.isra.7+0x4c/0x18c
> [   13.039480] [<ffff800000152130>] oom_kill_process+0x26c/0x45c
> [   13.045243] [<ffff800000152688>] out_of_memory+0x2e0/0x32c
> [   13.050745] [<ffff800000156c68>] __alloc_pages_nodemask+0x83c/0x848
> [   13.057031] [<ffff800000156f78>] alloc_kmem_pages_node+0x30/0xa8
> [   13.063058] [<ffff8000000b776c>] copy_process.isra.42.part.43+0x128/0x1488
> [   13.069955] [<ffff8000000b8c4c>] _do_fork+0xcc/0x338
> [   13.074934] [<ffff8000000b8f04>] kernel_thread+0x34/0x3c
> [   13.080261] [<ffff8000000cb8e0>] call_usermodehelper_exec_work+0x2c/0xd8
> [   13.086984] [<ffff8000000ce4b0>] process_one_work+0x134/0x2f4
> [   13.092747] [<ffff8000000ce6c8>] worker_thread+0x58/0x43c
> [   13.098162] [<ffff8000000d3f88>] kthread+0xd8/0xec
> [   13.102967] [<ffff800000085cd0>] ret_from_fork+0x10/0x40
> [   13.261745] Mem-Info:
> 
> Thanks and Regards
> Harry++

-- 
Thanks,
-Takahiro AKASHI

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-11  0:53                   ` AKASHI Takahiro
@ 2016-05-11 11:06                     ` Harninder Rai
  2016-05-13 12:45                     ` Harninder Rai
  1 sibling, 0 replies; 19+ messages in thread
From: Harninder Rai @ 2016-05-11 11:06 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Takahiro Akashi,

> >
> > I used a smaller initramfs (as you suggested) and my crash kernel has
> moved further but it again dumped with the following log messages. Any
> further pointers?
> 
> It seems that you have already reached the point of kicking up "init"
> process, and this means that crash dump kernel itself successfully booted.
Yes, I too thought the same
> 
> > Does this mean that there isn't enough memory to save the core file or
> > something? Because the error mostly are related to OOM killer process
> 
> Apparently lack of memory is a cause of OOM killer, but the core file has
> nothing to do with this issue.
> I think that you don't have enough memory for the system yet.
Looks like there's only few MBs space left on my rootfs. Let me try shifting to secondary storage for storing the rootfs or maybe use chroot

Once again, thanks for the help

Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-11  0:53                   ` AKASHI Takahiro
  2016-05-11 11:06                     ` Harninder Rai
@ 2016-05-13 12:45                     ` Harninder Rai
  2016-05-19 11:03                       ` AKASHI Takahiro
  1 sibling, 1 reply; 19+ messages in thread
From: Harninder Rai @ 2016-05-13 12:45 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Takahiro Akashi,

> 
> Apparently lack of memory is a cause of OOM killer, but the core file has
> nothing to do with this issue.
> I think that you don't have enough memory for the system yet.
> 
> -Takahiro AKASHI


I moved to SD card based rootfs for booting the crash kernel but when I try to load the dump kernel, I get the following message
Is there limitation with kexec that the crash kernel cannot be booted from anything apart from RAM?

kexec -p ./vmlinux --initrd=./ramdisk_ls1012_openwrt.cpio.gz --append='console=ttyS1,115200 root=/dev/mmcblk0p1 earlycon=uart8250,mmio,0x21c0600ramdisk_size=0x2000000 default_hugepagesz=2m hugepagesz=2m hugepages=256 crashkernel=64M at 2240M memblock=debug'
Memory for crashkernel is not reserved
Please reserve memory by passing"crashkernel=X at Y" parameter to kernel
Then try to loading kdump kernel

Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-04-05  5:23               ` AKASHI Takahiro
  2016-04-05 10:42                 ` Harninder Rai
  2016-05-10 12:32                 ` Harninder Rai
@ 2016-05-19 10:48                 ` Harninder Rai
  2 siblings, 0 replies; 19+ messages in thread
From: Harninder Rai @ 2016-05-19 10:48 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Takahiro Akashi,

Do you have any further suggestions?

Regards
Harry++

> -----Original Message-----
> From: Harninder Rai
> Sent: Tuesday, May 10, 2016 6:02 PM
> To: 'AKASHI Takahiro'
> Cc: Geoff Levand; linux-arm-kernel at lists.infradead.org
> Subject: RE: Help needed with kexec on arm64
> 
> >
> > This means that there is no enough space left at this point.
> > I guess that you are using too big initramfs against 64MB of total memory.
> > Just increase the memory size for crash dump kernel.
> >
> > -Takahiro AKASHI
> 
> Hello Takahiro Akashi,
> 
> I used a smaller initramfs (as you suggested) and my crash kernel has moved
> further but it again dumped with the following log messages. Any further
> pointers?
> Does this mean that there isn't enough memory to save the core file or
> something? Because the error mostly are related to OOM killer process
> 
> [    8.833434] Freeing unused kernel memory: 748K (ffff800000a3a000 -
> ffff800000af5000)
> [    8.848924] init: Console is alive
> [    8.856866] mmc0: new high speed SDHC card at address b368
> [    8.868239] mmcblk0: mmc0:b368 SDC   3.75 GiB
> [    8.873913]  mmcblk0: p1
> [    9.855930] init: - preinit -
> Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2],
> [3] or [4] key and hit [enter] to select the debug level
> [   12.896779] procd: - early -
> [   12.977417] kworker/u16:0 invoked oom-killer: gfp_mask=0x27000c0,
> order=2, oom_score_adj=0
> [   12.994568] CPU: 0 PID: 6 Comm: kworker/u16:0 Not tainted 4.5.0-rc6-
> 00038-gae2804a-dirty #5
> [   13.002950] Hardware name: Freescale Layerscape 2085a RDB Board (DT)
> [   13.009333] Workqueue: events_unbound call_usermodehelper_exec_work
> [   13.015623] Call trace:
> [   13.018076] [<ffff800000089760>] dump_backtrace+0x0/0x1ac
> [   13.023492] [<ffff800000089920>] show_stack+0x14/0x1c
> [   13.028560] [<ffff80000032c1d4>] dump_stack+0x8c/0xb0
> [   13.033627] [<ffff8000001aebdc>] dump_header.isra.7+0x4c/0x18c
> [   13.039480] [<ffff800000152130>] oom_kill_process+0x26c/0x45c
> [   13.045243] [<ffff800000152688>] out_of_memory+0x2e0/0x32c
> [   13.050745] [<ffff800000156c68>] __alloc_pages_nodemask+0x83c/0x848
> [   13.057031] [<ffff800000156f78>] alloc_kmem_pages_node+0x30/0xa8
> [   13.063058] [<ffff8000000b776c>]
> copy_process.isra.42.part.43+0x128/0x1488
> [   13.069955] [<ffff8000000b8c4c>] _do_fork+0xcc/0x338
> [   13.074934] [<ffff8000000b8f04>] kernel_thread+0x34/0x3c
> [   13.080261] [<ffff8000000cb8e0>] call_usermodehelper_exec_work+0x2c/0xd8
> [   13.086984] [<ffff8000000ce4b0>] process_one_work+0x134/0x2f4
> [   13.092747] [<ffff8000000ce6c8>] worker_thread+0x58/0x43c
> [   13.098162] [<ffff8000000d3f88>] kthread+0xd8/0xec
> [   13.102967] [<ffff800000085cd0>] ret_from_fork+0x10/0x40
> [   13.261745] Mem-Info:
> 
> Thanks and Regards
> Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-13 12:45                     ` Harninder Rai
@ 2016-05-19 11:03                       ` AKASHI Takahiro
  2016-05-19 13:53                         ` Harninder Rai
  2016-05-27 11:51                         ` Harninder Rai
  0 siblings, 2 replies; 19+ messages in thread
From: AKASHI Takahiro @ 2016-05-19 11:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, May 13, 2016 at 12:45:04PM +0000, Harninder Rai wrote:
> Hello Takahiro Akashi,
> 
> > 
> > Apparently lack of memory is a cause of OOM killer, but the core file has
> > nothing to do with this issue.
> > I think that you don't have enough memory for the system yet.
> > 
> > -Takahiro AKASHI
> 
> 
> I moved to SD card based rootfs for booting the crash kernel but when I try to load the dump kernel, I get the following message
> Is there limitation with kexec that the crash kernel cannot be booted from anything apart from RAM?

I don't know what you did here exactly, but I don't think that
there is such a limitation.

> kexec -p ./vmlinux --initrd=./ramdisk_ls1012_openwrt.cpio.gz --append='console=ttyS1,115200 root=/dev/mmcblk0p1 earlycon=uart8250,mmio,0x21c0600ramdisk_size=0x2000000 default_hugepagesz=2m hugepagesz=2m hugepages=256 crashkernel=64M at 2240M memblock=debug'
> Memory for crashkernel is not reserved

This message is a hint. You have got the same one before, right?
Please check /proc/iomem and a dmesg log from the first kernel
with memblock=debug.

-Takahiro AKASHI

> Please reserve memory by passing"crashkernel=X at Y" parameter to kernel
> Then try to loading kdump kernel
> 
> Regards
> Harry++

-- 
Thanks,
-Takahiro AKASHI

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-19 11:03                       ` AKASHI Takahiro
@ 2016-05-19 13:53                         ` Harninder Rai
  2016-05-27 11:51                         ` Harninder Rai
  1 sibling, 0 replies; 19+ messages in thread
From: Harninder Rai @ 2016-05-19 13:53 UTC (permalink / raw)
  To: linux-arm-kernel

> 
> I don't know what you did here exactly, but I don't think that there is such
> a limitation.
Ok. Thanks for the confirmation
> 
> > kexec -p ./vmlinux --initrd=./ramdisk_ls1012_openwrt.cpio.gz --
> append='console=ttyS1,115200 root=/dev/mmcblk0p1
> earlycon=uart8250,mmio,0x21c0600ramdisk_size=0x2000000 default_hugepagesz=2m
> hugepagesz=2m hugepages=256 crashkernel=64M at 2240M memblock=debug'
> > Memory for crashkernel is not reserved
> 
> This message is a hint. You have got the same one before, right?
> Please check /proc/iomem and a dmesg log from the first kernel with
> memblock=debug.
I did check /proc/iomem and everything looks there. This is very strange since if I keep everything same and just move the rootfs from RAM based to SD based, I start getting this issue. 

Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-19 11:03                       ` AKASHI Takahiro
  2016-05-19 13:53                         ` Harninder Rai
@ 2016-05-27 11:51                         ` Harninder Rai
  2016-05-27 13:58                           ` Russell King - ARM Linux
  2016-05-31  0:34                           ` AKASHI Takahiro
  1 sibling, 2 replies; 19+ messages in thread
From: Harninder Rai @ 2016-05-27 11:51 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Takahiro Akashi,

Please see the following log which I was talking about in my last communication
Any idea as to what could be wrong just when I move from RAM based rootfs to SD based rootfs?

> I did check /proc/iomem and everything looks there. This is very strange
> since if I keep everything same and just move the rootfs from RAM based to
> SD based, I start getting this issue.

root at ls2085ardb:/# kexec -p ./vmlinux.wor --initrd=./initramfs_arm64_busybox1_22_1_with_coremark.cpio.gz --append='console=ttyS1,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0600ramdisk_size=0x2000000 default_hugepagesz=2m hugepagesz=2m hugepages=256 memblock=debug maxcpus=1'
Memory for crashkernel is not reserved
Please reserve memory by passing"crashkernel=X at Y" parameter to kernel
Then try to loading kdump kernel
root at ls2085ardb:/# cat /proc/iomem
02000000-0200ffff : /i2c at 2000000
02140000-0214ffff : mmc0
021c0500-021c05ff : serial
021c0600-021c06ff : serial
03100000-03107fff : /usb3 at 3100000
0310c100-0310ffff : /usb3 at 3100000
03110000-03117fff : /usb3 at 3110000
0311c100-0311ffff : /usb3 at 3110000
05000000-057fffff : /iommu at 5000000
80000000-ffffffff : System RAM
  80080000-80a39333 : Kernel code
  80af5000-80bd4fff : Kernel data
  8c000000-8fffffff : Crash kernel
80c000000-80c00003f : mc_portal

Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-27 11:51                         ` Harninder Rai
@ 2016-05-27 13:58                           ` Russell King - ARM Linux
  2016-05-27 19:19                             ` Geoff Levand
  2016-05-30 11:07                             ` Harninder Rai
  2016-05-31  0:34                           ` AKASHI Takahiro
  1 sibling, 2 replies; 19+ messages in thread
From: Russell King - ARM Linux @ 2016-05-27 13:58 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, May 27, 2016 at 11:51:03AM +0000, Harninder Rai wrote:
> Hello Takahiro Akashi,
> 
> Please see the following log which I was talking about in my last communication
> Any idea as to what could be wrong just when I move from RAM based rootfs to SD based rootfs?
> 
> > I did check /proc/iomem and everything looks there. This is very strange
> > since if I keep everything same and just move the rootfs from RAM based to
> > SD based, I start getting this issue.

You should be able to get more information by using kexec -d to enable
debug output... if the architecture is usefully printing stuff like
memory layouts etc.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-27 13:58                           ` Russell King - ARM Linux
@ 2016-05-27 19:19                             ` Geoff Levand
  2016-05-30 11:10                               ` Harninder Rai
  2016-05-30 11:07                             ` Harninder Rai
  1 sibling, 1 reply; 19+ messages in thread
From: Geoff Levand @ 2016-05-27 19:19 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, 2016-05-27 at 14:58 +0100, Russell King - ARM Linux wrote:
> On Fri, May 27, 2016 at 11:51:03AM +0000, Harninder Rai wrote:Hello Takahiro Akashi,
> > 
> > Please see the following log which I was talking about in my last communication
> > Any idea as to what could be wrong just when I move from RAM based rootfs to SD based rootfs?

> debug output... if the architecture is usefully printing stuff like
> memory layouts etc.
You should be able to get more information by using kexec -d to enable

Also, use the latest from here:

  git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git
  
-Geoff

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-27 13:58                           ` Russell King - ARM Linux
  2016-05-27 19:19                             ` Geoff Levand
@ 2016-05-30 11:07                             ` Harninder Rai
  1 sibling, 0 replies; 19+ messages in thread
From: Harninder Rai @ 2016-05-30 11:07 UTC (permalink / raw)
  To: linux-arm-kernel

> 
> You should be able to get more information by using kexec -d to enable debug
> output... if the architecture is usefully printing stuff like memory layouts
> etc.
Unfortunately, kexec -d didn't give any additional information in this case :(
Any more pointers?

Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-27 19:19                             ` Geoff Levand
@ 2016-05-30 11:10                               ` Harninder Rai
  0 siblings, 0 replies; 19+ messages in thread
From: Harninder Rai @ 2016-05-30 11:10 UTC (permalink / raw)
  To: linux-arm-kernel

> Also, use the latest from here:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/geoff/kexec-tools.git

I am using kexec -v
kexec version: 16.03.14.10.05-gef652df-dirty
kexec-tools 2.0.12-rc1

Do you think still later version will help in this case?

Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
  2016-05-27 11:51                         ` Harninder Rai
  2016-05-27 13:58                           ` Russell King - ARM Linux
@ 2016-05-31  0:34                           ` AKASHI Takahiro
  1 sibling, 0 replies; 19+ messages in thread
From: AKASHI Takahiro @ 2016-05-31  0:34 UTC (permalink / raw)
  To: linux-arm-kernel

On 05/27/2016 08:51 PM, Harninder Rai wrote:
> Hello Takahiro Akashi,
>
> Please see the following log which I was talking about in my last communication
> Any idea as to what could be wrong just when I move from RAM based rootfs to SD based rootfs?
>
>> I did check /proc/iomem and everything looks there. This is very strange
>> since if I keep everything same and just move the rootfs from RAM based to
>> SD based, I start getting this issue.
>
> root at ls2085ardb:/# kexec -p ./vmlinux.wor --initrd=./initramfs_arm64_busybox1_22_1_with_coremark.cpio.gz --append='console=ttyS1,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0600ramdisk_size=0x2000000 default_hugepagesz=2m hugepagesz=2m hugepages=256 memblock=debug maxcpus=1'
> Memory for crashkernel is not reserved
> Please reserve memory by passing"crashkernel=X at Y" parameter to kernel
> Then try to loading kdump kernel
> root at ls2085ardb:/# cat /proc/iomem
> 02000000-0200ffff : /i2c at 2000000
> 02140000-0214ffff : mmc0
> 021c0500-021c05ff : serial
> 021c0600-021c06ff : serial
> 03100000-03107fff : /usb3 at 3100000
> 0310c100-0310ffff : /usb3 at 3100000
> 03110000-03117fff : /usb3 at 3110000
> 0311c100-0311ffff : /usb3 at 3110000
> 05000000-057fffff : /iommu at 5000000
> 80000000-ffffffff : System RAM
>    80080000-80a39333 : Kernel code
>    80af5000-80bd4fff : Kernel data
>    8c000000-8fffffff : Crash kernel
> 80c000000-80c00003f : mc_portal


Please trace is_crashkernel_mem_reserved() and kexec_iomem_for_each_line().

-Takahiro AKASHI

> Regards
> Harry++
>

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Help needed with kexec on arm64
@ 2016-03-17 16:57 Harninder Rai
  0 siblings, 0 replies; 19+ messages in thread
From: Harninder Rai @ 2016-03-17 16:57 UTC (permalink / raw)
  To: linux-arm-kernel

Hello Takahiro Akashi/Geoff,

I was trying to run kexec on NXP's ls2085ardb board (based on arm64) but I am facing following issue

root at ls2085ardb:~# kexec -p /run/media/mmcblk0p1/vmlinux
Memory for crashkernel is not reserved
Please reserve memory by passing"crashkernel=X at Y" parameter to kernel
Then try to loading kdump kernel

I am using git://git.kernel.org/pub/scm/linux/kernel/git/geoff/linux-kexec.git commit ae2804a21b4686df02890027e64c11088439854c

I have done the following in bootargs
--------------------------------------------------

dmesg |grep crash -i
[    0.000000] Reserving 64MB of memory at 2240MB for crashkernel
[    0.000000] Kernel command line: console=ttyS1,115200 root=/dev/ram0 earlycon=uart8250,mmio,0x21c0600 ramdisk_size=0x200000 default_hugepagesz=2m hugepagesz=2m hugepages=256 crashkernel=64M at 2240M

All the required kernel configs are also enabled
--------------------------------------------------

root at ls2085ardb:~# zcat /proc/config.gz |grep -i sysfs
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_SYSFS_SYSCALL=y
# CONFIG_GPIO_SYSFS is not set
CONFIG_RTC_INTF_SYSFS=y
# CONFIG_DMI_SYSFS is not set
CONFIG_SYSFS=y
root at ls2085ardb:~# zcat /proc/config.gz |grep -i kexec
CONFIG_KEXEC_CORE=y
CONFIG_KEXEC=y
root at ls2085ardb:~# zcat /proc/config.gz |grep -i kdump
root at ls2085ardb:~# zcat /proc/config.gz |grep -i debug_info
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_INFO_SPLIT is not set
# CONFIG_DEBUG_INFO_DWARF4 is not set
root at ls2085ardb:~# zcat /proc/config.gz |grep -i crash
CONFIG_CRASH_DUMP=y


Any pointer in this regard would be much appreciated

Thanks and Regards
Harry++

^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2016-05-31  0:34 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <DB5PR04MB168845795D86B4CE5BA5656FE68B0@DB5PR04MB1688.eurprd04.prod.outlook.com>
     [not found] ` <1458230896.3391.18.camel@infradead.org>
     [not found]   ` <CAB5YjtBEO=efjhcFdVOaZqG13qK3uzCbS5SFym5hhw-n+_QLhw@mail.gmail.com>
     [not found]     ` <DB5PR04MB1688A6D4385B76DAFF71D364E68C0@DB5PR04MB1688.eurprd04.prod.outlook.com>
     [not found]       ` <CAB5YjtAqjL8LMvNPbxwVWe+Zhi5rFkz_X7rti9wSrXQ7Y_2kOA@mail.gmail.com>
     [not found]         ` <DB5PR04MB16880834700413C3B80194B5E68C0@DB5PR04MB1688.eurprd04.prod.outlook.com>
     [not found]           ` <CAB5YjtCP6M9=ESJhfxyyYKSGTg8s3Y83qp8RS_oyYkUqcqYcCw@mail.gmail.com>
2016-03-21 10:27             ` Help needed with kexec on arm64 Harninder Rai
     [not found]               ` <CAB5YjtCoX5FoRbOYTPCETbbBGmEvs=1Xm6Giho78TH_a7u=eXw@mail.gmail.com>
2016-03-22 17:49                 ` Harninder Rai
2016-04-04 10:49             ` Harninder Rai
2016-04-05  5:23               ` AKASHI Takahiro
2016-04-05 10:42                 ` Harninder Rai
2016-05-10 12:32                 ` Harninder Rai
2016-05-11  0:53                   ` AKASHI Takahiro
2016-05-11 11:06                     ` Harninder Rai
2016-05-13 12:45                     ` Harninder Rai
2016-05-19 11:03                       ` AKASHI Takahiro
2016-05-19 13:53                         ` Harninder Rai
2016-05-27 11:51                         ` Harninder Rai
2016-05-27 13:58                           ` Russell King - ARM Linux
2016-05-27 19:19                             ` Geoff Levand
2016-05-30 11:10                               ` Harninder Rai
2016-05-30 11:07                             ` Harninder Rai
2016-05-31  0:34                           ` AKASHI Takahiro
2016-05-19 10:48                 ` Harninder Rai
2016-03-17 16:57 Harninder Rai

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.