* RE: kdump issues with 4.11 kernel @ 2017-11-29 5:29 Gurumurthy, Anil 2017-11-29 7:38 ` Dave Young 0 siblings, 1 reply; 9+ messages in thread From: Gurumurthy, Anil @ 2017-11-29 5:29 UTC (permalink / raw) To: kexec 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kdump issues with 4.11 kernel 2017-11-29 5:29 kdump issues with 4.11 kernel Gurumurthy, Anil @ 2017-11-29 7:38 ` Dave Young 2017-11-29 9:14 ` Gurumurthy, Anil 0 siblings, 1 reply; 9+ messages in thread From: Dave Young @ 2017-11-29 7:38 UTC (permalink / raw) To: Gurumurthy, Anil; +Cc: kexec 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: kdump issues with 4.11 kernel 2017-11-29 7:38 ` Dave Young @ 2017-11-29 9:14 ` Gurumurthy, Anil 2017-11-29 9:46 ` Bhupesh Sharma 0 siblings, 1 reply; 9+ messages in thread From: Gurumurthy, Anil @ 2017-11-29 9:14 UTC (permalink / raw) To: Dave Young; +Cc: kexec 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kdump issues with 4.11 kernel 2017-11-29 9:14 ` Gurumurthy, Anil @ 2017-11-29 9:46 ` Bhupesh Sharma 2017-11-29 10:06 ` Gurumurthy, Anil 0 siblings, 1 reply; 9+ messages in thread From: Bhupesh Sharma @ 2017-11-29 9:46 UTC (permalink / raw) To: Gurumurthy, Anil; +Cc: kexec, Dave Young 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: kdump issues with 4.11 kernel 2017-11-29 9:46 ` Bhupesh Sharma @ 2017-11-29 10:06 ` Gurumurthy, Anil 2017-11-29 10:19 ` Bhupesh Sharma 0 siblings, 1 reply; 9+ messages in thread From: Gurumurthy, Anil @ 2017-11-29 10:06 UTC (permalink / raw) To: Bhupesh Sharma; +Cc: kexec, Dave Young -----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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kdump issues with 4.11 kernel 2017-11-29 10:06 ` Gurumurthy, Anil @ 2017-11-29 10:19 ` Bhupesh Sharma 2017-11-29 10:31 ` Gurumurthy, Anil 2017-11-30 12:29 ` Gurumurthy, Anil 0 siblings, 2 replies; 9+ messages in thread From: Bhupesh Sharma @ 2017-11-29 10:19 UTC (permalink / raw) To: Gurumurthy, Anil; +Cc: kexec, Dave Young 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: kdump issues with 4.11 kernel 2017-11-29 10:19 ` Bhupesh Sharma @ 2017-11-29 10:31 ` Gurumurthy, Anil 2017-11-30 12:29 ` Gurumurthy, Anil 1 sibling, 0 replies; 9+ messages in thread From: Gurumurthy, Anil @ 2017-11-29 10:31 UTC (permalink / raw) To: Bhupesh Sharma; +Cc: kexec, Dave Young -----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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: kdump issues with 4.11 kernel 2017-11-29 10:19 ` Bhupesh Sharma 2017-11-29 10:31 ` Gurumurthy, Anil @ 2017-11-30 12:29 ` Gurumurthy, Anil 2017-12-04 19:59 ` Bhupesh Sharma 1 sibling, 1 reply; 9+ messages in thread From: Gurumurthy, Anil @ 2017-11-30 12:29 UTC (permalink / raw) To: Bhupesh Sharma; +Cc: kexec, Dave Young 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: kdump issues with 4.11 kernel 2017-11-30 12:29 ` Gurumurthy, Anil @ 2017-12-04 19:59 ` Bhupesh Sharma 0 siblings, 0 replies; 9+ messages in thread From: Bhupesh Sharma @ 2017-12-04 19:59 UTC (permalink / raw) To: Gurumurthy, Anil; +Cc: kexec, Dave Young 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-12-04 20:00 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-11-29 5:29 kdump issues with 4.11 kernel Gurumurthy, Anil 2017-11-29 7:38 ` Dave Young 2017-11-29 9:14 ` Gurumurthy, Anil 2017-11-29 9:46 ` Bhupesh Sharma 2017-11-29 10:06 ` Gurumurthy, Anil 2017-11-29 10:19 ` Bhupesh Sharma 2017-11-29 10:31 ` Gurumurthy, Anil 2017-11-30 12:29 ` Gurumurthy, Anil 2017-12-04 19:59 ` Bhupesh Sharma
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.