RE: kdump issues with 4.11 kernel

RE: kdump issues with 4.11 kernel

[Gurumurthy, Anil]

Hello,
  I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?

[root@localhost ~]# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`kdump.img
ELF core (kcore) parse failed
Cannot load /boot/vmlinuz-4.11.12+

[root@localhost ~]# ls -l /boot/vmlinuz-4.11.12+
-rw-r--r--. 1 root root 6404384 Nov 23 12:14 /boot/vmlinuz-4.11.12+
[root@localhost ~]# cat /sys/kernel/kexec_crash_size
134217728
[root@localhost ~]# cat /proc/iomem | grep -i crash
  30000000-37ffffff : Crash kernel

[root@localhost ~]# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`kdump.img -d
kernel: 0x7fa8ba785010 kernel_size: 0x61b920
MEMORY RANGES
0000000000000100-000000000006bfff (0)
000000000006c000-000000000006cfff (3)
000000000006d000-000000000009efff (0)
000000000009f000-000000000009ffff (3)
0000000000100000-000000004578d017 (0)
000000004578d018-00000000457aee57 (0)
00000000457aee58-00000000457af017 (0)
00000000457af018-00000000457d0e57 (0)
00000000457d0e58-00000000457d1017 (0)
00000000457d1018-00000000457f2e57 (0)
00000000457f2e58-00000000457f3017 (0)
00000000457f3018-0000000045814e57 (0)
0000000045814e58-0000000045815017 (0)
0000000045815018-000000004584ec57 (0)
000000004584ec58-000000004584f017 (0)
000000004584f018-0000000045888c57 (0)
0000000045888c58-000000005d13c017 (0)
000000005d13c018-000000005d14b057 (0)
000000005d14b058-000000005d14c017 (0)
000000005d14c018-000000005d15f657 (0)
000000005d15f658-000000005d184fff (0)
000000005d185000-000000005d185fff (2)
000000005d186000-000000005fb76fff (0)
000000005fb77000-000000005fb7bfff (1)
000000005fb7c000-000000005ffe0fff (0)
000000005ffe1000-000000005ffe1fff (2)
000000005ffe2000-000000005fff9fff (0)
000000005fffa000-0000000060001fff (2)
0000000060002000-0000000060009fff (0)
000000006000a000-000000006000afff (2)
000000006000b000-000000006000bfff (0)
000000006000c000-0000000060011fff (2)
0000000060012000-00000000600ddfff (0)
00000000600de000-00000000600e0fff (2)
00000000600e1000-00000000600e2fff (1)
00000000600e3000-00000000600e4fff (2)
00000000600e5000-00000000606e2fff (0)
00000000606e3000-00000000606e3fff (2)
00000000606e4000-0000000060e52fff (0)
0000000060e53000-0000000060e53fff (2)
0000000060e54000-00000000735d9fff (0)
00000000735da000-00000000735e6fff (1)
00000000735e7000-0000000074413fff (0)
0000000074414000-000000007e892fff (1)
000000007e893000-000000007eb9efff (3)
000000007eb9f000-000000007ec01fff (0)
0000000080000000-000000008fffffff (1)
00000000fed1c000-00000000fed1ffff (1)
00000000ff800000-00000000ffffffff (1)
0000000100000000-0000000a7fffffff (0)
0000000000000000-0000000000000fff : reserved
0000000000001000-000000000006bfff : System RAM
000000000006c000-000000000006cfff : ACPI Non-volatile Storage
000000000006d000-000000000009efff : System RAM
000000000009f000-000000000009ffff : ACPI Non-volatile Storage
00000000000a0000-00000000000bffff : PCI Bus 0000:00
00000000000c0000-00000000000c7fff : Video ROM
00000000000f0000-00000000000fffff : System ROM
0000000000100000-000000004578d017 : System RAM
0000000030000000-0000000037ffffff : Crash kernel
000000004578d018-00000000457aee57 : System RAM
00000000457aee58-00000000457af017 : System RAM
00000000457af018-00000000457d0e57 : System RAM
00000000457d0e58-00000000457d1017 : System RAM
00000000457d1018-00000000457f2e57 : System RAM
00000000457f2e58-00000000457f3017 : System RAM
00000000457f3018-0000000045814e57 : System RAM
0000000045814e58-0000000045815017 : System RAM
0000000045815018-000000004584ec57 : System RAM
000000004584ec58-000000004584f017 : System RAM
000000004584f018-0000000045888c57 : System RAM
0000000045888c58-000000005d13c017 : System RAM
000000005d13c018-000000005d14b057 : System RAM
000000005d14b058-000000005d14c017 : System RAM
000000005d14c018-000000005d15f657 : System RAM
000000005d15f658-000000005d184fff : System RAM
000000005d185000-000000005d185fff : ACPI Tables
000000005d186000-000000005fb76fff : System RAM
000000005fb77000-000000005fb7bfff : reserved
000000005fb7c000-000000005ffe0fff : System RAM
000000005ffe1000-000000005ffe1fff : ACPI Tables
000000005ffe2000-000000005fff9fff : System RAM
000000005fffa000-0000000060001fff : ACPI Tables
0000000060002000-0000000060009fff : System RAM
000000006000a000-000000006000afff : ACPI Tables
000000006000b000-000000006000bfff : System RAM
000000006000c000-0000000060011fff : ACPI Tables
0000000060012000-00000000600ddfff : System RAM
00000000600de000-00000000600e0fff : ACPI Tables
00000000600e1000-00000000600e2fff : reserved
00000000600e3000-00000000600e4fff : ACPI Tables
00000000600e5000-00000000606e2fff : System RAM
00000000606e3000-00000000606e3fff : ACPI Tables
00000000606e4000-0000000060e52fff : System RAM
0000000060e53000-0000000060e53fff : ACPI Tables
0000000060e54000-00000000735d9fff : System RAM
00000000735da000-00000000735e6fff : reserved
00000000735e7000-0000000074413fff : System RAM
0000000074414000-000000007e892fff : reserved
000000007e893000-000000007eb9efff : ACPI Non-volatile Storage
000000007eb9f000-000000007ec01fff : System RAM
000000007ec02000-000000007fffffff : RAM buffer
0000000080000000-000000008fffffff : PCI MMCONFIG 0000 [bus 00-ff]
0000000080000000-000000008fffffff : reserved
0000000090000000-00000000c3ff7fff : PCI Bus 0000:80
0000000090000000-0000000090003fff : 0000:80:04.0
0000000090000000-0000000090003fff : ioatdma
0000000090004000-0000000090007fff : 0000:80:04.1
0000000090004000-0000000090007fff : ioatdma
0000000090008000-000000009000bfff : 0000:80:04.2
0000000090008000-000000009000bfff : ioatdma
000000009000c000-000000009000ffff : 0000:80:04.3
000000009000c000-000000009000ffff : ioatdma
0000000090010000-0000000090013fff : 0000:80:04.4
0000000090010000-0000000090013fff : ioatdma
0000000090014000-0000000090017fff : 0000:80:04.5
0000000090014000-0000000090017fff : ioatdma
0000000090018000-000000009001bfff : 0000:80:04.6
0000000090018000-000000009001bfff : ioatdma
000000009001c000-000000009001ffff : 0000:80:04.7
000000009001c000-000000009001ffff : ioatdma
00000000c3ff8000-00000000c3ff8fff : dmar0
00000000c4000000-00000000fbff7fff : PCI Bus 0000:00
00000000c4000000-00000000c40fffff : PCI Bus 0000:20
00000000c4000000-00000000c403ffff : 0000:20:00.0
00000000c4040000-00000000c407ffff : 0000:20:00.1
00000000c42fd000-00000000c42fd3ff : 0000:00:1a.0
00000000c42fd000-00000000c42fd3ff : ehci_hcd
00000000c42fe000-00000000c42fe3ff : 0000:00:1d.0
00000000c42fe000-00000000c42fe3ff : ehci_hcd
00000000c42ff000-00000000c42ff7ff : 0000:00:1f.2
00000000c42ff000-00000000c42ff7ff : ahci
00000000c4300000-00000000c43fffff : PCI Bus 0000:16
00000000c4300000-00000000c431ffff : 0000:16:00.0
00000000c43bc000-00000000c43bffff : 0000:16:00.0
00000000c43bc000-00000000c43bffff : megasas: LSI
00000000c43c0000-00000000c43fffff : 0000:16:00.0
00000000c4400000-00000000c45fffff : PCI Bus 0000:06
00000000c4470000-00000000c4473fff : 0000:06:00.0
00000000c4470000-00000000c4473fff : igb
00000000c4474000-00000000c4493fff : 0000:06:00.0
00000000c4494000-00000000c44b3fff : 0000:06:00.0
00000000c44b4000-00000000c44b7fff : 0000:06:00.1
00000000c44b4000-00000000c44b7fff : igb
00000000c44b8000-00000000c44d7fff : 0000:06:00.1
00000000c44d8000-00000000c44f7fff : 0000:06:00.1
00000000c44f8000-00000000c44fbfff : 0000:06:00.2
00000000c44f8000-00000000c44fbfff : igb
00000000c44fc000-00000000c451bfff : 0000:06:00.2
00000000c451c000-00000000c453bfff : 0000:06:00.2
00000000c453c000-00000000c453ffff : 0000:06:00.3
00000000c453c000-00000000c453ffff : igb
00000000c4540000-00000000c455ffff : 0000:06:00.3
00000000c4560000-00000000c457ffff : 0000:06:00.3
00000000c4580000-00000000c459ffff : 0000:06:00.0
00000000c4580000-00000000c459ffff : igb
00000000c45a0000-00000000c45bffff : 0000:06:00.1
00000000c45a0000-00000000c45bffff : igb
00000000c45c0000-00000000c45dffff : 0000:06:00.2
00000000c45c0000-00000000c45dffff : igb
00000000c45e0000-00000000c45fffff : 0000:06:00.3
00000000c45e0000-00000000c45fffff : igb
00000000c4600000-00000000c4ffffff : PCI Bus 0000:01
00000000c4600000-00000000c4ffffff : PCI Bus 0000:02
00000000c4600000-00000000c46fffff : PCI Bus 0000:05
00000000c4700000-00000000c4ffffff : PCI Bus 0000:03
00000000c4700000-00000000c4ffffff : PCI Bus 0000:04
00000000c47fc000-00000000c47fffff : 0000:04:00.0
00000000c47fc000-00000000c47fffff : mgadrmfb_mmio
00000000c4800000-00000000c4ffffff : 0000:04:00.0
00000000c5000000-00000000c5ffffff : PCI Bus 0000:01
00000000c5000000-00000000c5ffffff : PCI Bus 0000:02
00000000c5000000-00000000c5ffffff : PCI Bus 0000:03
00000000c5000000-00000000c5ffffff : PCI Bus 0000:04
00000000c5000000-00000000c5ffffff : 0000:04:00.0
00000000c5000000-00000000c5ffffff : mgadrmfb_vram
00000000c60e0000-00000000c60e3fff : 0000:00:04.0
00000000c60e0000-00000000c60e3fff : ioatdma
00000000c60e4000-00000000c60e7fff : 0000:00:04.1
00000000c60e4000-00000000c60e7fff : ioatdma
00000000c60e8000-00000000c60ebfff : 0000:00:04.2
00000000c60e8000-00000000c60ebfff : ioatdma
00000000c60ec000-00000000c60effff : 0000:00:04.3
00000000c60ec000-00000000c60effff : ioatdma
00000000c60f0000-00000000c60f3fff : 0000:00:04.4
00000000c60f0000-00000000c60f3fff : ioatdma
00000000c60f4000-00000000c60f7fff : 0000:00:04.5
00000000c60f4000-00000000c60f7fff : ioatdma
00000000c60f8000-00000000c60fbfff : 0000:00:04.6
00000000c60f8000-00000000c60fbfff : ioatdma
00000000c60fc000-00000000c60fffff : 0000:00:04.7
00000000c60fc000-00000000c60fffff : ioatdma
00000000c6100000-00000000c63fffff : PCI Bus 0000:20
00000000c61fa000-00000000c61fafff : 0000:20:00.0
00000000c61fa000-00000000c61fafff : qla2xxx
00000000c61fb000-00000000c61fbfff : 0000:20:00.1
00000000c61fb000-00000000c61fbfff : qla2xxx
00000000c61fc000-00000000c61fdfff : 0000:20:00.0
00000000c61fc000-00000000c61fdfff : qla2xxx
00000000c61fe000-00000000c61fffff : 0000:20:00.1
00000000c61fe000-00000000c61fffff : qla2xxx
00000000c6200000-00000000c62fffff : 0000:20:00.0
00000000c6200000-00000000c62fffff : qla2xxx
00000000c6300000-00000000c63fffff : 0000:20:00.1
00000000c6300000-00000000c63fffff : qla2xxx
00000000fbff8000-00000000fbff8fff : dmar1
00000000fec00000-00000000fecfffff : PNP0003:00
00000000fec00000-00000000fec003ff : IOAPIC 0
00000000fec01000-00000000fec013ff : IOAPIC 1
00000000fec40000-00000000fec403ff : IOAPIC 2
00000000fed00000-00000000fed003ff : HPET 0
00000000fed00000-00000000fed003ff : PNP0103:00
00000000fed1b000-00000000fed1bfff : pnp 00:01
00000000fed1c000-00000000fed1ffff : reserved
00000000fed1f410-00000000fed1f414 : iTCO_wdt.0.auto
00000000fed40000-00000000fedfffff : PCI Bus 0000:00
00000000fed40000-00000000fed44fff : TPM
00000000fee00000-00000000feefffff : pnp 00:01
00000000fee00000-00000000fee00fff : Local APIC
00000000ff800000-00000000ffffffff : reserved
0000000100000000-0000000a7fffffff : System RAM
00000007e7600000-00000007e7d62a60 : Kernel code
00000007e7d62a61-00000007e838c9ff : Kernel data
00000007e85c6000-00000007e88dcfff : Kernel bss
0000038000000000-00000387ffffffff : PCI Bus 0000:00
0000038800000000-0000038fffffffff : PCI Bus 0000:80
get_backup_area: 0000000000001000-000000000006bfff : System RAM
CRASH MEMORY RANGES
0000000000000000-0000000000000fff (1)
0000000000001000-000000000006bfff (0)
000000000006c000-000000000006cfff (3)
000000000006d000-000000000009efff (0)
000000000009f000-000000000009ffff (3)
0000000000100000-000000002fffffff (0)
0000000038000000-000000004578d017 (0)
000000004578d018-00000000457aee57 (0)
00000000457aee58-00000000457af017 (0)
00000000457af018-00000000457d0e57 (0)
00000000457d0e58-00000000457d1017 (0)
00000000457d1018-00000000457f2e57 (0)
00000000457f2e58-00000000457f3017 (0)
00000000457f3018-0000000045814e57 (0)
0000000045814e58-0000000045815017 (0)
0000000045815018-000000004584ec57 (0)
000000004584ec58-000000004584f017 (0)
000000004584f018-0000000045888c57 (0)
0000000045888c58-000000005d13c017 (0)
000000005d13c018-000000005d14b057 (0)
000000005d14b058-000000005d14c017 (0)
000000005d14c018-000000005d15f657 (0)
000000005d15f658-000000005d184fff (0)
000000005d185000-000000005d185fff (2)
000000005d186000-000000005fb76fff (0)
000000005fb77000-000000005fb7bfff (1)
000000005fb7c000-000000005ffe0fff (0)
000000005ffe1000-000000005ffe1fff (2)
000000005ffe2000-000000005fff9fff (0)
000000005fffa000-0000000060001fff (2)
0000000060002000-0000000060009fff (0)
000000006000a000-000000006000afff (2)
000000006000b000-000000006000bfff (0)
000000006000c000-0000000060011fff (2)
0000000060012000-00000000600ddfff (0)
00000000600de000-00000000600e0fff (2)
00000000600e1000-00000000600e2fff (1)
00000000600e3000-00000000600e4fff (2)
00000000600e5000-00000000606e2fff (0)
00000000606e3000-00000000606e3fff (2)
00000000606e4000-0000000060e52fff (0)
0000000060e53000-0000000060e53fff (2)
0000000060e54000-00000000735d9fff (0)
00000000735da000-00000000735e6fff (1)
00000000735e7000-0000000074413fff (0)
0000000074414000-000000007e892fff (1)
000000007e893000-000000007eb9efff (3)
000000007eb9f000-000000007ec01fff (0)
0000000080000000-000000008fffffff (1)
00000000fed1c000-00000000fed1ffff (1)
00000000ff800000-00000000ffffffff (1)
0000000100000000-0000000a7fffffff (0)
kernel load physical addr start = 0x00000007e7600000
ELF core (kcore) parse failed
Cannot load /boot/vmlinuz-4.11.12+

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump issues with 4.11 kernel

[Dave Young]

Hi,
On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
> Hello,
>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
> 
> [root@localhost ~]# kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname -r`kdump.img
> ELF core (kcore) parse failed
> Cannot load /boot/vmlinuz-4.11.12+
> 

Can you try below kexec-tools commit:
commit ed15ba1b9977e506637ff1697821d97127b2c919
Author: Pratyush Anand <panand@redhat.com>
Date:   Wed Mar 1 11:19:42 2017 +0530

    build_mem_phdrs(): check if p_paddr is invalid

Thanks
Dave

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump issues with 4.11 kernel

[Gurumurthy, Anil]

Thanks. That did help getting kexec to work.
However I still do not get a crash dump - 
echo c  > /proc/sysrq-trigger does not get a crash dump.

Any thoughts?

Thanks,
Anil

-----Original Message-----
From: Dave Young [mailto:dyoung@redhat.com] 
Sent: 29 November 2017 13:09
To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
Cc: kexec@lists.infradead.org
Subject: Re: kdump issues with 4.11 kernel

Hi,
On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
> Hello,
>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
> 
> [root@localhost ~]# kexec -p /boot/vmlinuz-`uname -r` 
> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse 
> failed Cannot load /boot/vmlinuz-4.11.12+
> 

Can you try below kexec-tools commit:
commit ed15ba1b9977e506637ff1697821d97127b2c919
Author: Pratyush Anand <panand@redhat.com>
Date:   Wed Mar 1 11:19:42 2017 +0530

    build_mem_phdrs(): check if p_paddr is invalid

Thanks
Dave

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump issues with 4.11 kernel

[Bhupesh Sharma]

Hi Anil,

On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil
<Anil.Gurumurthy@cavium.com> wrote:
> Thanks. That did help getting kexec to work.
> However I still do not get a crash dump -
> echo c  > /proc/sysrq-trigger does not get a crash dump.
>
> Any thoughts?

Cam you share the console messages you see when the crash kernel
boots? Or do you see nothing after the crash is introduced via echo c
> /proc/sysrq-trigger

Generally, depending on your test machine arch, it is useful to use
earlycon/earlyprintk to see if the crash kernel produced any useful
message until the actual console device became operational.

Can you try setting the earlycon/earlyprintk settings and share the
crash kernel logs messages after the same?

Thanks,
Bhupesh

> -----Original Message-----
> From: Dave Young [mailto:dyoung@redhat.com]
> Sent: 29 November 2017 13:09
> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
> Cc: kexec@lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> Hi,
> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>> Hello,
>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>
>> [root@localhost ~]# kexec -p /boot/vmlinuz-`uname -r`
>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse
>> failed Cannot load /boot/vmlinuz-4.11.12+
>>
>
> Can you try below kexec-tools commit:
> commit ed15ba1b9977e506637ff1697821d97127b2c919
> Author: Pratyush Anand <panand@redhat.com>
> Date:   Wed Mar 1 11:19:42 2017 +0530
>
>     build_mem_phdrs(): check if p_paddr is invalid
>
> Thanks
> Dave
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump issues with 4.11 kernel

[Gurumurthy, Anil]

-----Original Message-----
From: Bhupesh Sharma [mailto:bhsharma@redhat.com] 
Sent: 29 November 2017 15:16
To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
Cc: Dave Young <dyoung@redhat.com>; kexec@lists.infradead.org
Subject: Re: kdump issues with 4.11 kernel

Hi Anil,

On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil <Anil.Gurumurthy@cavium.com> wrote:
> Thanks. That did help getting kexec to work.
> However I still do not get a crash dump - echo c  > 
> /proc/sysrq-trigger does not get a crash dump.
>
> Any thoughts?

Cam you share the console messages you see when the crash kernel boots? Or do you see nothing after the crash is introduced via echo c
> /proc/sysrq-trigger
[Anil]  I do not see any messages after introducing the crash.

Generally, depending on your test machine arch, it is useful to use earlycon/earlyprintk to see if the crash kernel produced any useful message until the actual console device became operational.

Can you try setting the earlycon/earlyprintk settings and share the crash kernel logs messages after the same?

Thanks,
Bhupesh

> -----Original Message-----
> From: Dave Young [mailto:dyoung@redhat.com]
> Sent: 29 November 2017 13:09
> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
> Cc: kexec@lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> Hi,
> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>> Hello,
>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>
>> [root@localhost ~]# kexec -p /boot/vmlinuz-`uname -r` 
>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse 
>> failed Cannot load /boot/vmlinuz-4.11.12+
>>
>
> Can you try below kexec-tools commit:
> commit ed15ba1b9977e506637ff1697821d97127b2c919
> Author: Pratyush Anand <panand@redhat.com>
> Date:   Wed Mar 1 11:19:42 2017 +0530
>
>     build_mem_phdrs(): check if p_paddr is invalid
>
> Thanks
> Dave
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump issues with 4.11 kernel

[Bhupesh Sharma]

On Wed, Nov 29, 2017 at 3:36 PM, Gurumurthy, Anil
<Anil.Gurumurthy@cavium.com> wrote:
>
>
> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
> Sent: 29 November 2017 15:16
> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
> Cc: Dave Young <dyoung@redhat.com>; kexec@lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> Hi Anil,
>
> On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil <Anil.Gurumurthy@cavium.com> wrote:
>> Thanks. That did help getting kexec to work.
>> However I still do not get a crash dump - echo c  >
>> /proc/sysrq-trigger does not get a crash dump.
>>
>> Any thoughts?
>
> Cam you share the console messages you see when the crash kernel boots? Or do you see nothing after the crash is introduced via echo c
>> /proc/sysrq-trigger
> [Anil]  I do not see any messages after introducing the crash.

There could be several reasons for this:

- crashkernel might be missing some arch/machine specific options.
- It may be that the purgatory sha verification has failed. If your
arch supports a console in purgatory then it is easy to debug this.
- It might be that the crash kernel itself crashed very early. Pass
some earlycon/earlyprintk option for your system to the second kernel
command line.
- Also please share relevant dmesg log of both primary kernel boot and
the commands you use to invoke the crashkernel.

Regards,
Bhupesh


> Generally, depending on your test machine arch, it is useful to use earlycon/earlyprintk to see if the crash kernel produced any useful message until the actual console device became operational.
>
> Can you try setting the earlycon/earlyprintk settings and share the crash kernel logs messages after the same?
>
> Thanks,
> Bhupesh
>
>> -----Original Message-----
>> From: Dave Young [mailto:dyoung@redhat.com]
>> Sent: 29 November 2017 13:09
>> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
>> Cc: kexec@lists.infradead.org
>> Subject: Re: kdump issues with 4.11 kernel
>>
>> Hi,
>> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>>> Hello,
>>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>>
>>> [root@localhost ~]# kexec -p /boot/vmlinuz-`uname -r`
>>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse
>>> failed Cannot load /boot/vmlinuz-4.11.12+
>>>
>>
>> Can you try below kexec-tools commit:
>> commit ed15ba1b9977e506637ff1697821d97127b2c919
>> Author: Pratyush Anand <panand@redhat.com>
>> Date:   Wed Mar 1 11:19:42 2017 +0530
>>
>>     build_mem_phdrs(): check if p_paddr is invalid
>>
>> Thanks
>> Dave
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump issues with 4.11 kernel

[Gurumurthy, Anil]

-----Original Message-----
From: Bhupesh Sharma [mailto:bhsharma@redhat.com] 
Sent: 29 November 2017 15:50
To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
Cc: Dave Young <dyoung@redhat.com>; kexec@lists.infradead.org
Subject: Re: kdump issues with 4.11 kernel

On Wed, Nov 29, 2017 at 3:36 PM, Gurumurthy, Anil <Anil.Gurumurthy@cavium.com> wrote:
>
>
> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
> Sent: 29 November 2017 15:16
> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
> Cc: Dave Young <dyoung@redhat.com>; kexec@lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> Hi Anil,
>
> On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil <Anil.Gurumurthy@cavium.com> wrote:
>> Thanks. That did help getting kexec to work.
>> However I still do not get a crash dump - echo c  > 
>> /proc/sysrq-trigger does not get a crash dump.
>>
>> Any thoughts?
>
> Cam you share the console messages you see when the crash kernel 
> boots? Or do you see nothing after the crash is introduced via echo c
>> /proc/sysrq-trigger
> [Anil]  I do not see any messages after introducing the crash.

There could be several reasons for this:

- crashkernel might be missing some arch/machine specific options.
- It may be that the purgatory sha verification has failed. If your arch supports a console in purgatory then it is easy to debug this.
- It might be that the crash kernel itself crashed very early. Pass some earlycon/earlyprintk option for your system to the second kernel command line.
- Also please share relevant dmesg log of both primary kernel boot and the commands you use to invoke the crashkernel.

[Anil] Thanks for the quick response

   This is what I have in the .config (for the primary kernel)
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_EARLY_PRINTK_EFI=y

The log for the primary kernel boot:

Nov 29 14:22:22 localhost journal: Runtime journal is using 8.0M (max 1.9G, leaving 2.9G of free 19.4G, current limit 1.9G).
Nov 29 14:22:22 localhost kernel: Linux version 4.11.12+ (root@localhost.localdomain) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #4 SMP Thu Nov 23 12:11:02 IST 2017
Nov 29 14:22:22 localhost kernel: Command line: BOOT_IMAGE=/vmlinuz-4.11.12+ root=/dev/mapper/rhel-root ro rd.lvm.lv=rhel/swap crashkernel=128M rd.lvm.lv=rhel/root rhgb quiet
Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
Nov 29 14:22:22 localhost kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Nov 29 14:22:22 localhost kernel: e820: BIOS-provided physical RAM map:
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000006bfff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000006c000-0x000000000006cfff] ACPI NVS
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000006d000-0x000000000009efff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] ACPI NVS
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x000000005d184fff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005d185000-0x000000005d185fff] ACPI data
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005d186000-0x000000005fb77fff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fb78000-0x000000005fb7cfff] reserved
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fb7d000-0x000000005ffdffff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005ffe0000-0x000000005ffe1fff] ACPI data
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005ffe2000-0x000000005fffafff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fffb000-0x0000000060001fff] ACPI data
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060002000-0x0000000060009fff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000006000a000-0x000000006000efff] ACPI data
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000006000f000-0x000000006000ffff] usable
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060010000-0x0000000060011fff] ACPI data
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060012000-0x00000000600ddfff] usable


Will try to get the other details you needed too.

-Anil

Regards,
Bhupesh


> Generally, depending on your test machine arch, it is useful to use earlycon/earlyprintk to see if the crash kernel produced any useful message until the actual console device became operational.
>
> Can you try setting the earlycon/earlyprintk settings and share the crash kernel logs messages after the same?
>
> Thanks,
> Bhupesh
>
>> -----Original Message-----
>> From: Dave Young [mailto:dyoung@redhat.com]
>> Sent: 29 November 2017 13:09
>> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
>> Cc: kexec@lists.infradead.org
>> Subject: Re: kdump issues with 4.11 kernel
>>
>> Hi,
>> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>>> Hello,
>>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>>
>>> [root@localhost ~]# kexec -p /boot/vmlinuz-`uname -r` 
>>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse 
>>> failed Cannot load /boot/vmlinuz-4.11.12+
>>>
>>
>> Can you try below kexec-tools commit:
>> commit ed15ba1b9977e506637ff1697821d97127b2c919
>> Author: Pratyush Anand <panand@redhat.com>
>> Date:   Wed Mar 1 11:19:42 2017 +0530
>>
>>     build_mem_phdrs(): check if p_paddr is invalid
>>
>> Thanks
>> Dave
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

RE: kdump issues with 4.11 kernel

[Gurumurthy, Anil]

Hi Bhupesh,
  I tried to get some log messages for the crash kernel, but unable to get anything.
echo c > /proc/sysrq-trigger
simply hangs w/o any messages on the console.

Thanks,
Anil
-----Original Message-----
From: Gurumurthy, Anil 
Sent: 29 November 2017 16:02
To: 'Bhupesh Sharma' <bhsharma@redhat.com>
Cc: Dave Young <dyoung@redhat.com>; kexec@lists.infradead.org
Subject: RE: kdump issues with 4.11 kernel



-----Original Message-----
From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
Sent: 29 November 2017 15:50
To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
Cc: Dave Young <dyoung@redhat.com>; kexec@lists.infradead.org
Subject: Re: kdump issues with 4.11 kernel

On Wed, Nov 29, 2017 at 3:36 PM, Gurumurthy, Anil <Anil.Gurumurthy@cavium.com> wrote:
>
>
> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
> Sent: 29 November 2017 15:16
> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
> Cc: Dave Young <dyoung@redhat.com>; kexec@lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> Hi Anil,
>
> On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil <Anil.Gurumurthy@cavium.com> wrote:
>> Thanks. That did help getting kexec to work.
>> However I still do not get a crash dump - echo c  > 
>> /proc/sysrq-trigger does not get a crash dump.
>>
>> Any thoughts?
>
> Cam you share the console messages you see when the crash kernel 
> boots? Or do you see nothing after the crash is introduced via echo c
>> /proc/sysrq-trigger
> [Anil]  I do not see any messages after introducing the crash.

There could be several reasons for this:

- crashkernel might be missing some arch/machine specific options.
- It may be that the purgatory sha verification has failed. If your arch supports a console in purgatory then it is easy to debug this.
- It might be that the crash kernel itself crashed very early. Pass some earlycon/earlyprintk option for your system to the second kernel command line.
- Also please share relevant dmesg log of both primary kernel boot and the commands you use to invoke the crashkernel.

[Anil] Thanks for the quick response

   This is what I have in the .config (for the primary kernel) CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_EARLY_PRINTK_EFI=y

The log for the primary kernel boot:

Nov 29 14:22:22 localhost journal: Runtime journal is using 8.0M (max 1.9G, leaving 2.9G of free 19.4G, current limit 1.9G).
Nov 29 14:22:22 localhost kernel: Linux version 4.11.12+ (root@localhost.localdomain) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #4 SMP Thu Nov 23 12:11:02 IST 2017 Nov 29 14:22:22 localhost kernel: Command line: BOOT_IMAGE=/vmlinuz-4.11.12+ root=/dev/mapper/rhel-root ro rd.lvm.lv=rhel/swap crashkernel=128M rd.lvm.lv=rhel/root rhgb quiet Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
Nov 29 14:22:22 localhost kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256 Nov 29 14:22:22 localhost kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
Nov 29 14:22:22 localhost kernel: e820: BIOS-provided physical RAM map:
Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000006bfff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000006c000-0x000000000006cfff] ACPI NVS Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000006d000-0x000000000009efff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] ACPI NVS Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x000000005d184fff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005d185000-0x000000005d185fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005d186000-0x000000005fb77fff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fb78000-0x000000005fb7cfff] reserved Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fb7d000-0x000000005ffdffff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005ffe0000-0x000000005ffe1fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005ffe2000-0x000000005fffafff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fffb000-0x0000000060001fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060002000-0x0000000060009fff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000006000a000-0x000000006000efff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000006000f000-0x000000006000ffff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060010000-0x0000000060011fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060012000-0x00000000600ddfff] usable


Will try to get the other details you needed too.

-Anil

Regards,
Bhupesh


> Generally, depending on your test machine arch, it is useful to use earlycon/earlyprintk to see if the crash kernel produced any useful message until the actual console device became operational.
>
> Can you try setting the earlycon/earlyprintk settings and share the crash kernel logs messages after the same?
>
> Thanks,
> Bhupesh
>
>> -----Original Message-----
>> From: Dave Young [mailto:dyoung@redhat.com]
>> Sent: 29 November 2017 13:09
>> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
>> Cc: kexec@lists.infradead.org
>> Subject: Re: kdump issues with 4.11 kernel
>>
>> Hi,
>> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>>> Hello,
>>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>>
>>> [root@localhost ~]# kexec -p /boot/vmlinuz-`uname -r` 
>>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse 
>>> failed Cannot load /boot/vmlinuz-4.11.12+
>>>
>>
>> Can you try below kexec-tools commit:
>> commit ed15ba1b9977e506637ff1697821d97127b2c919
>> Author: Pratyush Anand <panand@redhat.com>
>> Date:   Wed Mar 1 11:19:42 2017 +0530
>>
>>     build_mem_phdrs(): check if p_paddr is invalid
>>
>> Thanks
>> Dave
>>
>> _______________________________________________
>> kexec mailing list
>> kexec@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/kexec
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Re: kdump issues with 4.11 kernel

[Bhupesh Sharma]

Hello Anil,

On Thu, Nov 30, 2017 at 5:59 PM, Gurumurthy, Anil
<Anil.Gurumurthy@cavium.com> wrote:
> Hi Bhupesh,
>   I tried to get some log messages for the crash kernel, but unable to get anything.
> echo c > /proc/sysrq-trigger
> simply hangs w/o any messages on the console.

Did you tree to set earlycon or earlyprintk in the bootargs. Something
like this:

earlycon=pl011,mmio32,0xff78ed1000

depending on the underlying uart device you have on the board. For
e.g. here I assumed a pl011 uart is used to display console messages.

Regards,
Bhupesh

>
> Thanks,
> Anil
> -----Original Message-----
> From: Gurumurthy, Anil
> Sent: 29 November 2017 16:02
> To: 'Bhupesh Sharma' <bhsharma@redhat.com>
> Cc: Dave Young <dyoung@redhat.com>; kexec@lists.infradead.org
> Subject: RE: kdump issues with 4.11 kernel
>
>
>
> -----Original Message-----
> From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
> Sent: 29 November 2017 15:50
> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
> Cc: Dave Young <dyoung@redhat.com>; kexec@lists.infradead.org
> Subject: Re: kdump issues with 4.11 kernel
>
> On Wed, Nov 29, 2017 at 3:36 PM, Gurumurthy, Anil <Anil.Gurumurthy@cavium.com> wrote:
>>
>>
>> -----Original Message-----
>> From: Bhupesh Sharma [mailto:bhsharma@redhat.com]
>> Sent: 29 November 2017 15:16
>> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
>> Cc: Dave Young <dyoung@redhat.com>; kexec@lists.infradead.org
>> Subject: Re: kdump issues with 4.11 kernel
>>
>> Hi Anil,
>>
>> On Wed, Nov 29, 2017 at 2:44 PM, Gurumurthy, Anil <Anil.Gurumurthy@cavium.com> wrote:
>>> Thanks. That did help getting kexec to work.
>>> However I still do not get a crash dump - echo c  >
>>> /proc/sysrq-trigger does not get a crash dump.
>>>
>>> Any thoughts?
>>
>> Cam you share the console messages you see when the crash kernel
>> boots? Or do you see nothing after the crash is introduced via echo c
>>> /proc/sysrq-trigger
>> [Anil]  I do not see any messages after introducing the crash.
>
> There could be several reasons for this:
>
> - crashkernel might be missing some arch/machine specific options.
> - It may be that the purgatory sha verification has failed. If your arch supports a console in purgatory then it is easy to debug this.
> - It might be that the crash kernel itself crashed very early. Pass some earlycon/earlyprintk option for your system to the second kernel command line.
> - Also please share relevant dmesg log of both primary kernel boot and the commands you use to invoke the crashkernel.
>
> [Anil] Thanks for the quick response
>
>    This is what I have in the .config (for the primary kernel) CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_EARLY_PRINTK_EFI=y
>
> The log for the primary kernel boot:
>
> Nov 29 14:22:22 localhost journal: Runtime journal is using 8.0M (max 1.9G, leaving 2.9G of free 19.4G, current limit 1.9G).
> Nov 29 14:22:22 localhost kernel: Linux version 4.11.12+ (root@localhost.localdomain) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC) ) #4 SMP Thu Nov 23 12:11:02 IST 2017 Nov 29 14:22:22 localhost kernel: Command line: BOOT_IMAGE=/vmlinuz-4.11.12+ root=/dev/mapper/rhel-root ro rd.lvm.lv=rhel/swap crashkernel=128M rd.lvm.lv=rhel/root rhgb quiet Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
> Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> Nov 29 14:22:22 localhost kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> Nov 29 14:22:22 localhost kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256 Nov 29 14:22:22 localhost kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
> Nov 29 14:22:22 localhost kernel: e820: BIOS-provided physical RAM map:
> Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000006bfff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000006c000-0x000000000006cfff] ACPI NVS Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000006d000-0x000000000009efff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] ACPI NVS Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000000100000-0x000000005d184fff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005d185000-0x000000005d185fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005d186000-0x000000005fb77fff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fb78000-0x000000005fb7cfff] reserved Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fb7d000-0x000000005ffdffff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005ffe0000-0x000000005ffe1fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005ffe2000-0x000000005fffafff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000005fffb000-0x0000000060001fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060002000-0x0000000060009fff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000006000a000-0x000000006000efff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x000000006000f000-0x000000006000ffff] usable Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060010000-0x0000000060011fff] ACPI data Nov 29 14:22:22 localhost kernel: BIOS-e820: [mem 0x0000000060012000-0x00000000600ddfff] usable
>
>
> Will try to get the other details you needed too.
>
> -Anil
>
> Regards,
> Bhupesh
>
>
>> Generally, depending on your test machine arch, it is useful to use earlycon/earlyprintk to see if the crash kernel produced any useful message until the actual console device became operational.
>>
>> Can you try setting the earlycon/earlyprintk settings and share the crash kernel logs messages after the same?
>>
>> Thanks,
>> Bhupesh
>>
>>> -----Original Message-----
>>> From: Dave Young [mailto:dyoung@redhat.com]
>>> Sent: 29 November 2017 13:09
>>> To: Gurumurthy, Anil <Anil.Gurumurthy@cavium.com>
>>> Cc: kexec@lists.infradead.org
>>> Subject: Re: kdump issues with 4.11 kernel
>>>
>>> Hi,
>>> On 11/29/17 at 05:29am, Gurumurthy, Anil wrote:
>>>> Hello,
>>>>   I was facing trouble getting a crash dump on 4.11 kernel. Debugging a bit, I see that the kexec run from the cmd line fails. Any ideas on what I could be missing?
>>>>
>>>> [root@localhost ~]# kexec -p /boot/vmlinuz-`uname -r`
>>>> --initrd=/boot/initramfs-`uname -r`kdump.img ELF core (kcore) parse
>>>> failed Cannot load /boot/vmlinuz-4.11.12+
>>>>
>>>
>>> Can you try below kexec-tools commit:
>>> commit ed15ba1b9977e506637ff1697821d97127b2c919
>>> Author: Pratyush Anand <panand@redhat.com>
>>> Date:   Wed Mar 1 11:19:42 2017 +0530
>>>
>>>     build_mem_phdrs(): check if p_paddr is invalid
>>>
>>> Thanks
>>> Dave
>>>
>>> _______________________________________________
>>> kexec mailing list
>>> kexec@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec