Description of problem: kdump: saving vmcore failed on Fedora-31 hpe-apollo-cn99xx VM. # uname -r 5.5.7-200.fc31.aarch64 # cat /proc/cmdline BOOT_IMAGE=(hd0,gpt2)/vmlinuz-5.5.7-200.fc31.aarch64 root=/dev/mapper/fedora_hpe--apollo--cn99xx--14--vm--14-root ro rd.lvm.lv=fedora_hpe-apollo-cn99xx-14-vm-14/root rd.lvm.lv=fedora_hpe-apollo-cn99xx-14-vm-14/swap crashkernel=512M # rpm -q kexec-tools kexec-tools-2.0.20-9.fc31.aarch64 # cat /etc/kdump.conf path /var/crash core_collector makedumpfile -l --message-level 1 -d 31 -D Console log: ... kdump: saving vmcore makedumpfile: version 1.6.7 (released on 16 Jan 2020) command line: makedumpfile -l --message-level 1 -d 31 -D /proc/vmcore /sysroot//var/crash/127.0.0.1-2020-03-09-01:41:53/vmcore-incomplete sadump: unsupported architecture phys_start phys_end virt_start virt_end LOAD[ 0] 77210000 79840000 ffffab831e410000 ffffab8320a40000 LOAD[ 1] 40000000 e0000000 ffffc00000000000 ffffc000a0000000 LOAD[ 2] 100000000 1bbf10000 ffffc000c0000000 ffffc0017bf10000 LOAD[ 3] 1bc000000 1bc040000 ffffc0017c000000 ffffc0017c040000 LOAD[ 4] 1bc3d0000 1bf6b0000 ffffc0017c3d0000 ffffc0017f6b0000 LOAD[ 5] 1bf740000 1bf750000 ffffc0017f740000 ffffc0017f750000 LOAD[ 6] 1bf870000 1c0000000 ffffc0017f870000 ffffc00180000000 Linux kdump VMCOREINFO : OSRELEASE=5.5.7-200.fc31.aarch64 PAGESIZE=4096 page_size : 4096 SYMBOL(init_uts_ns)=ffffab831fc6b568 SYMBOL(node_online_map)=ffffab831fc64550 SYMBOL(swapper_pg_dir)=ffffab831f61d000 SYMBOL(_stext)=ffffab831e411000 SYMBOL(vmap_area_list)=ffffab831fcee7b8 SYMBOL(mem_section)=ffff00017f1f7000 LENGTH(mem_section)=1024 SIZE(mem_section)=16 OFFSET(mem_section.section_mem_map)=0 SIZE(page)=64 SIZE(pglist_data)=73728 SIZE(zone)=1856 SIZE(free_area)=104 SIZE(list_head)=16 SIZE(nodemask_t)=64 OFFSET(page.flags)=0 OFFSET(page._refcount)=52 OFFSET(page.mapping)=24 OFFSET(page.lru)=8 OFFSET(page._mapcount)=48 OFFSET(page.private)=40 OFFSET(page.compound_dtor)=16 OFFSET(page.compound_order)=17 OFFSET(page.compound_head)=8 OFFSET(pglist_data.node_zones)=0 OFFSET(pglist_data.nr_zones)=72992 OFFSET(pglist_data.node_start_pfn)=73000 OFFSET(pglist_data.node_spanned_pages)=73016 OFFSET(pglist_data.node_id)=73024 OFFSET(zone.free_area)=192 OFFSET(zone.vm_stat)=1664 OFFSET(zone.spanned_pages)=112 OFFSET(free_area.free_list)=0 OFFSET(list_head.next)=0 OFFSET(list_head.prev)=8 OFFSET(vmap_area.va_start)=0 OFFSET(vmap_area.list)=40 LENGTH(zone.free_area)=13 SYMBOL(log_buf)=ffffab831fc98678 SYMBOL(log_buf_len)=ffffab831fc98670 SYMBOL(log_first_idx)=ffffab83202f35bc SYMBOL(clear_idx)=ffffab83202f35c8 SYMBOL(log_next_idx)=ffffab83202f35b8 SIZE(printk_log)=16 OFFSET(printk_log.ts_nsec)=0 OFFSET(printk_log.len)=8 OFFSET(printk_log.text_len)=10 OFFSET(printk_log.dict_len)=12 LENGTH(free_area.free_list)=6 NUMBER(NR_FREE_PAGES)=0 NUMBER(PG_lru)=4 NUMBER(PG_private)=13 NUMBER(PG_swapcache)=10 NUMBER(PG_swapbacked)=19 NUMBER(PG_slab)=9 NUMBER(PG_hwpoison)=22 NUMBER(PG_head_mask)=65536 NUMBER(PAGE_BUDDY_MAPCOUNT_VALUE)=-129 NUMBER(HUGETLB_PAGE_DTOR)=2 NUMBER(PAGE_OFFLINE_MAPCOUNT_VALUE)=-257 NUMBER(VA_BITS)=48 NUMBER(kimage_voffset)=0xffffab82a7200000 NUMBER(PHYS_OFFSET)=0xffffab7040000000 KERNELOFFSET=2b830e390000 CRASHTIME=1583717900 phys_base : ffffab7040000000 (vmcoreinfo) max_mapnr : 1c0000 There is enough free memory to be done in one cycle. Buffer size for the cyclic mode: 458752 va_bits : 47 page_offset : ffffc00000000000 kdump: saving vmcore failed ... I changed the core_collector to cp and run makedumpfile against the vmcore saved directly from /proc/vmcore. It reported "PAGE SIZE 0x1000 and VA Bits 47 not supported." # makedumpfile -l -d 31 vmcore vmcore_1 calculate_plat_config: PAGE SIZE 0x1000 and VA Bits 47 not supported get_machdep_info_arm64: Can't determine platform config values makedumpfile Failed. Version-Release number of selected component (if applicable): Fedora-31 kernel-5.5.7-200.fc31.aarch64 kexec-tools-2.0.20-9.fc31.aarch64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I was able to reproduce it on 'hpe-apollo-cn99xx-14-vm-03.khw4.lab.eng.bos.redhat.com' with the following environment: [root@hpe-apollo-cn99xx-14-vm-03 ~]# uname -rn hpe-apollo-cn99xx-14-vm-03.khw4.lab.eng.bos.redhat.com 5.5.8-200.fc31.aarch64 [root@hpe-apollo-cn99xx-14-vm-03 ~]# rpm -qa kexec-tools kexec-tools-2.0.20-9.fc31.aarch64 As we can see the PAGE_SIZE configuration for aarch64 fedora (via '/boot/config-5.5.8-200.fc31.aarch64') is 4K, which means that we can support a maximum of 48-bit VA address (so this is not a 52-bit VA address use-case, which is possible only when PAGE_SIZE is 4K). I printed the _stext value on this platform and it seems the makedumpfile code gets confused while calculating the VA-bits (get_versiondep_info_arm64: _stext: ffffbf7dc2ac1000) I think the upstream makedumpfile code is buggy when it should be selecting VA-bits as 48, when PAGE_SIZE is 4K, as 47-bit VA-space is supported only when PAGE_SIZE is 16K - as per the arm64 kernel code: Kernel Kconfig file: arch/arm64/Kconfig --------------------------------------- config ARM64_VA_BITS_47 bool "47-bit" depends on ARM64_16K_PAGES I will send a patch to fix the makedumpfile issue upstream. Thanks.
Ok, looking further, I think this issue will be automatically fixed when I post the v6 52-bit kernel + makedumpfile changes for arm64 upstream. So, I will put this on LOW Priority and wait for the upstream fixes first. Thanks.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.