[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Changed in: makedumpfile (Debian) Status: New => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Released Status in makedumpfile source package in Bionic: Fix Released Status in makedumpfile source package in Eoan: Fix Released Status in makedumpfile source package in Focal: Fix Released Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: Fix Released Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Tags removed: sts-sponsor-mfo -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Released Status in makedumpfile source package in Bionic: Fix Released Status in makedumpfile source package in Eoan: Fix Released Status in makedumpfile source package in Focal: Fix Released Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
This bug was fixed in the package makedumpfile - 1:1.6.3-2~16.04.3 --- makedumpfile (1:1.6.3-2~16.04.3) xenial; urgency=medium * d/p/0004-align_PMD_SECTION_MASK_with_PHYS_MASK.patch (LP: #1869465) Fix error on arm64 with 1TB+ of physical or firmware-mapped RAM. -- Ioanna Alifieraki Thu, 04 Jun 2020 15:28:39 +0100 -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Released Status in makedumpfile source package in Bionic: Fix Released Status in makedumpfile source package in Eoan: Fix Released Status in makedumpfile source package in Focal: Fix Released Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
This bug was fixed in the package makedumpfile - 1:1.6.5-1ubuntu1~18.04.5 --- makedumpfile (1:1.6.5-1ubuntu1~18.04.5) bionic; urgency=medium * d/p/0006-align_PMD_SECTION_MASK_with_PHYS_MASK.patch (LP: #1869465) Fix error on arm64 with 1TB+ of physical or firmware-mapped RAM. -- Ioanna Alifieraki Thu, 04 Jun 2020 15:08:05 +0100 ** Changed in: makedumpfile (Ubuntu Bionic) Status: Fix Committed => Fix Released ** Changed in: makedumpfile (Ubuntu Xenial) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Released Status in makedumpfile source package in Bionic: Fix Released Status in makedumpfile source package in Eoan: Fix Released Status in makedumpfile source package in Focal: Fix Released Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
This bug was fixed in the package makedumpfile - 1:1.6.6-2ubuntu2.1 --- makedumpfile (1:1.6.6-2ubuntu2.1) eoan; urgency=medium * d/p/0004-align_PMD_SECTION_MASK_with_PHYS_MASK.patch (LP: #1869465) Fix error on arm64 with 1TB+ of physical or firmware-mapped RAM. -- Ioanna Alifieraki Thu, 04 Jun 2020 15:00:16 +0100 ** Changed in: makedumpfile (Ubuntu Eoan) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Released Status in makedumpfile source package in Focal: Fix Released Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
This bug was fixed in the package makedumpfile - 1:1.6.7-1ubuntu2.1 --- makedumpfile (1:1.6.7-1ubuntu2.1) focal; urgency=medium * d/p/0003-align_PMD_SECTION_MASK_with_PHYS_MASK.patch (LP: #1869465) Fix error on arm64 with 1TB+ of physical or firmware-mapped RAM. -- Ioanna Alifieraki Thu, 04 Jun 2020 14:47:17 +0100 ** Changed in: makedumpfile (Ubuntu Focal) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Released Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Verification done for Xenial: xenial-updates: failure. $ dpkg -s makedumpfile | grep -i version Version: 1:1.6.3-2~16.04.2 [8.647356] kdump-tools[507]: Starting kdump-tools: * running makedumpfile -c -d 31 /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171359/dump-incomplete [8.664692] kdump-tools[507]: mv: cannot stat '/var/crash/202006171359/dump-incomplete': No such file or directory [8.667714] kdump-tools[507]: * kdump-tools: saved vmcore in /var/crash/202006171359 [8.692230] kdump-tools[507]: * running makedumpfile --dump-dmesg /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171359/dmesg.202006171359 [8.708653] kdump-tools[507]: readmem: Can't convert a virtual address(6a2) to physical address. [8.710544] kdump-tools[507]: readmem: type_addr: 0, addr:6a2, size:1032 [8.712395] kdump-tools[507]: validate_mem_section: Can't read mem_section array. [8.716294] kdump-tools[507]: get_mem_section: Could not validate mem_section. [8.720306] kdump-tools[507]: get_mm_sparsemem: Can't get the address of mem_section. [8.724320] kdump-tools[507]: The kernel version is not supported. [8.725633] kdump-tools[507]: The makedumpfile operation may be incomplete. [8.728284] kdump-tools[507]: makedumpfile Failed. [8.731764] kdump-tools[507]: * kdump-tools: makedumpfile --dump-dmesg failed. dmesg content will be unavailable [8.736343] kdump-tools[507]: * kdump-tools: failed to save dmesg content in /var/crash/202006171359 [8.738431] kdump-tools[507]: Wed, 17 Jun 2020 13:59:30 + [8.746373] kdump-tools[507]: Rebooting. [8.798875] reboot: Restarting system xenial-proposed: success. $ dpkg -s makedumpfile | grep -i version Version: 1:1.6.3-2~16.04.3 [8.945076] kdump-tools[506]: Starting kdump-tools: * running makedumpfile -c -d 31 /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171401/dump-incomplete [8.957889] kdump-tools[506]: mv: cannot stat '/var/crash/202006171401/dump-incomplete': No such file or directory [8.960648] kdump-tools[506]: * kdump-tools: saved vmcore in /var/crash/202006171401 [8.978986] kdump-tools[506]: * running makedumpfile --dump-dmesg /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171401/dmesg.202006171401 [9.014422] kdump-tools[506]: The kernel version is not supported. [9.015867] kdump-tools[506]: The makedumpfile operation may be incomplete. [9.020309] kdump-tools[506]: The dmesg log is saved to /var/crash/202006171401/dmesg.202006171401. [9.022123] kdump-tools[506]: makedumpfile Completed. [9.024312] kdump-tools[506]: * kdump-tools: saved dmesg content in /var/crash/202006171401 [9.035973] kdump-tools[506]: Wed, 17 Jun 2020 14:01:41 + [9.045322] kdump-tools[506]: Rebooting. [9.096136] reboot: Restarting system ** Tags removed: verification-needed-xenial ** Tags added: verification-done-xenial ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Committed Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1]
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Verification done for Focal. focal (-release): failure: $ dpkg -s makedumpfile | grep -i version: Version: 1:1.6.7-1ubuntu2 [8.465657] kdump-tools[516]: Starting kdump-tools: * running makedumpfile -c -d 31 /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171302/dump-incomplete [8.478292] kdump-tools[516]: mv: cannot stat '/var/crash/202006171302/dump-incomplete': No such file or directory [8.481075] kdump-tools[516]: * kdump-tools: saved vmcore in /var/crash/202006171302 [8.510048] kdump-tools[516]: * running makedumpfile --dump-dmesg /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171302/dmesg.202006171302 [8.527350] kdump-tools[516]: readmem: Can't convert a virtual address(6a2) to physical address. [8.529301] kdump-tools[516]: readmem: type_addr: 0, addr:6a2, size:1032 [8.535281] kdump-tools[516]: validate_mem_section: Can't read mem_section array. [8.536957] kdump-tools[516]: get_mem_section: Could not validate mem_section. [8.539035] kdump-tools[516]: get_mm_sparsemem: Can't get the address of mem_section. [8.543546] kdump-tools[516]: makedumpfile Failed. [8.544785] kdump-tools[516]: * kdump-tools: makedumpfile --dump-dmesg failed. dmesg content will be unavailable [8.547530] kdump-tools[516]: * kdump-tools: failed to save dmesg content in /var/crash/202006171302 [8.552599] kdump-tools[516]: Wed, 17 Jun 2020 13:02:28 + [8.562610] kdump-tools[516]: Rebooting. [8.613739] reboot: Restarting system focal-proposed: success. $ dpkg -s makedumpfile | grep -i version: Version: 1:1.6.7-1ubuntu2.1 [8.578735] kdump-tools[505]: Starting kdump-tools: * running makedumpfile -c -d 31 /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171304/dump-incomplete [8.603615] kdump-tools[505]: mv: cannot stat '/var/crash/202006171304/dump-incomplete': No such file or directory [8.609175] kdump-tools[505]: * kdump-tools: saved vmcore in /var/crash/202006171304 [8.625685] kdump-tools[505]: * running makedumpfile --dump-dmesg /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171304/dmesg.202006171304 [8.660292] kdump-tools[505]: The dmesg log is saved to /var/crash/202006171304/dmesg.202006171304. [8.662197] kdump-tools[505]: makedumpfile Completed. [8.664300] kdump-tools[505]: * kdump-tools: saved dmesg content in /var/crash/202006171304 [8.677828] kdump-tools[505]: Wed, 17 Jun 2020 13:04:30 + [8.686921] kdump-tools[505]: Rebooting. [8.730789] reboot: Restarting system ** Tags removed: verification-needed-bionic verification-needed-eoan verification-needed-focal ** Tags added: verification-done-bionic verification-done-eoan verification-done-focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Committed Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Verification done for Eoan: eoan-updates: failure. $ dpkg -s makedumpfile | grep -i version Version: 1:1.6.6-2ubuntu2 [8.717056] kdump-tools[514]: Starting kdump-tools: * running makedumpfile -c -d 31 /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171254/dump-incomplete [8.725052] kdump-tools[514]: mv: cannot stat '/var/crash/202006171254/dump-incomplete': No such file or directory [8.727673] kdump-tools[514]: * kdump-tools: saved vmcore in /var/crash/202006171254 [8.748962] kdump-tools[514]: * running makedumpfile --dump-dmesg /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171254/dmesg.202006171254 [8.765998] kdump-tools[514]: readmem: Can't convert a virtual address(6a2) to physical address. [8.767925] kdump-tools[514]: readmem: type_addr: 0, addr:6a2, size:1032 [8.772332] kdump-tools[514]: validate_mem_section: Can't read mem_section array. [8.773832] kdump-tools[514]: get_mem_section: Could not validate mem_section. [8.776258] kdump-tools[514]: get_mm_sparsemem: Can't get the address of mem_section. [8.780311] kdump-tools[514]: makedumpfile Failed. [8.781415] kdump-tools[514]: * kdump-tools: makedumpfile --dump-dmesg failed. dmesg content will be unavailable [8.786166] kdump-tools[514]: * kdump-tools: failed to save dmesg content in /var/crash/202006171254 [8.790350] kdump-tools[514]: Wed, 17 Jun 2020 12:54:47 + [8.800156] kdump-tools[514]: Rebooting. [8.849905] reboot: Restarting system eoan-proposed: success. $ dpkg -s makedumpfile | grep -i version Version: 1:1.6.6-2ubuntu2.1 [8.595861] kdump-tools[517]: Starting kdump-tools: * running makedumpfile -c -d 31 /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171257/dump-incomplete [8.602814] kdump-tools[517]: mv: cannot stat '/var/crash/202006171257/dump-incomplete': No such file or directory [8.605489] kdump-tools[517]: * kdump-tools: saved vmcore in /var/crash/202006171257 [8.625608] kdump-tools[517]: * running makedumpfile --dump-dmesg /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171257/dmesg.202006171257 [8.662375] kdump-tools[517]: The dmesg log is saved to /var/crash/202006171257/dmesg.202006171257. [8.664378] kdump-tools[517]: makedumpfile Completed. [8.668322] kdump-tools[517]: * kdump-tools: saved dmesg content in /var/crash/202006171257 [8.679634] kdump-tools[517]: Wed, 17 Jun 2020 12:57:16 + [8.689315] kdump-tools[517]: Rebooting. [8.743280] reboot: Restarting system -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Committed Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Verification done for Bionic. bionic-updates: failure. $ dpkg -s makedumpfile | grep -i version Version: 1:1.6.5-1ubuntu1~18.04.4 [8.369266] kdump-tools[513]: Starting kdump-tools: * running makedumpfile -c -d 31 /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171242/dump-incomplete [8.382379] kdump-tools[513]: mv: cannot stat '/var/crash/202006171242/dump-incomplete': No such file or directory [8.385529] kdump-tools[513]: * kdump-tools: saved vmcore in /var/crash/202006171242 [8.405479] kdump-tools[513]: * running makedumpfile --dump-dmesg /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171242/dmesg.202006171242 [8.43] kdump-tools[513]: readmem: Can't convert a virtual address(6a2) to physical address. [8.424872] kdump-tools[513]: readmem: type_addr: 0, addr:6a2, size:1032 [8.428291] kdump-tools[513]: validate_mem_section: Can't read mem_section array. [8.429779] kdump-tools[513]: get_mem_section: Could not validate mem_section. [8.432257] kdump-tools[513]: get_mm_sparsemem: Can't get the address of mem_section. [8.436297] kdump-tools[513]: makedumpfile Failed. [8.439351] kdump-tools[513]: * kdump-tools: makedumpfile --dump-dmesg failed. dmesg content will be unavailable [8.442197] kdump-tools[513]: * kdump-tools: failed to save dmesg content in /var/crash/202006171242 [8.448570] kdump-tools[513]: Wed, 17 Jun 2020 12:42:16 + [8.455630] kdump-tools[513]: Rebooting. [8.514560] reboot: Restarting system bionic-proposed: success. $ dpkg -s makedumpfile | grep -i version Version: 1:1.6.5-1ubuntu1~18.04.5 [7.628682] kdump-tools[517]: Starting kdump-tools: * running makedumpfile -c -d 31 /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171249/dump-incomplete [7.642186] kdump-tools[517]: mv: cannot stat '/var/crash/202006171249/dump-incomplete': No such file or directory [7.644850] kdump-tools[517]: * kdump-tools: saved vmcore in /var/crash/202006171249 [7.662102] kdump-tools[517]: * running makedumpfile --dump-dmesg /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171249/dmesg.202006171249 [7.695277] kdump-tools[517]: The dmesg log is saved to /var/crash/202006171249/dmesg.202006171249. [7.697111] kdump-tools[517]: makedumpfile Completed. [7.699346] kdump-tools[517]: * kdump-tools: saved dmesg content in /var/crash/202006171249 [7.711560] kdump-tools[517]: Wed, 17 Jun 2020 12:49:41 + [7.720149] kdump-tools[517]: Rebooting. [7.776421] reboot: Restarting system -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Committed Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf:
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
The verification for makedumpfile used the vmcore file provided by another user instead of /proc/vmcore (which is identical, as it's a simple 'cp' copy of /proc/vmcore, per makedumpfile error.) $ ls -lh /home/ubuntu/201909170743/vmcore.201909170743 -r 1 ubuntu ubuntu 32G Sep 17 2019 /home/ubuntu/201909170743/vmcore.201909170743 $ file /home/ubuntu/201909170743/vmcore.201909170743 /home/ubuntu/201909170743/vmcore.201909170743: ELF 64-bit LSB core file ARM aarch64, version 1 (SYSV), SVR4-style The reproducer system is an arm64 guest in our internal openstack cloud with the same kernel version as the user (4.15.0-76-generic.) $ grep -ao -m1 'Linux version .* ' /home/ubuntu/201909170743/vmcore.201909170743 Linux version 4.15.0-76-generic (buildd@bos02-arm64-060) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #86-Ubuntu SMP Fri Jan 17 17:25:58 UTC 2020 (Ubuntu 4.15.0-76.86-generic $ uname -mrv 4.15.0-76-generic #86-Ubuntu SMP Fri Jan 17 17:25:58 UTC 2020 aarch64 When using the original package version, makedumpfile fails with error messages about a particular address, then kdump-tools (the caller of makedumpfile) falls back to 'cp', as reported. This takes a long time since it's a 32 GB file. So, since the second step / invocation of makedumpfile, to store the dmesg output on vmcore (makedumpfile --dump-dmesg), fails in the same way (and for the very same particular address), that is, an equivalent failure / symptom of the same root cause, then use only that step, which runs fast regardless of failure or success. These are the changes done to /usr/sbin/kdump-config (shell script independent of makedumpfile binary/executable code.) # Constants #vmcore_file=/proc/vmcore vmcore_file=/home/ubuntu/201909170743/vmcore.201909170743 ... function kdump_save_core() ... log_action_msg "running makedumpfile $MAKEDUMP_ARGS $vmcore_file $KDUMP_CORETEMP" #makedumpfile $MAKEDUMP_ARGS $vmcore_file $KDUMP_CORETEMP #ERROR=$? ERROR=0 if [ $ERROR -ne 0 ] ; then log_failure_msg "$NAME: makedumpfile failed, falling back to 'cp'" ... For documentation purposes, With the user's vmcore, and still collecting the crashdump (i.e., first invocation of makedumpfile), the exact error reproduces: $ dpkg -s makedumpfile | grep -i version Version: 1:1.6.5-1ubuntu1~18.04.4 $ echo 1 | sudo tee /proc/sys/kernel/sysrq && echo c | sudo tee /proc/sysrq-trigger ... [ 222.162389] sysrq: SysRq : Trigger a crash ... [ 222.185756] Call trace: [ 222.186091] sysrq_handle_crash+0x24/0x30 [ 222.186628] __handle_sysrq+0xbc/0x1c0 [ 222.187128] write_sysrq_trigger+0xb8/0x120 [ 222.187690] proc_reg_write+0x80/0xc0 [ 222.188182] __vfs_write+0x48/0x80 [ 222.188639] vfs_write+0xac/0x1b0 [ 222.189148] SyS_write+0x74/0xf0 [ 222.189585] el0_svc_naked+0x30/0x34 [ 222.190073] Code: 52800020 b90ca020 d5033e9f d281 (3920) [ 222.190892] SMP: stopping secondary CPUs [ 222.193873] Starting crashdump kernel... [ 222.194414] Bye! ... [8.168635] kdump-tools[516]: Starting kdump-tools: * running makedumpfile -c -d 31 /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171229/dump-incomplete [8.185786] kdump-tools[516]: readmem: Can't convert a virtual address(6a2) to physical address. [8.187727] kdump-tools[516]: readmem: type_addr: 0, addr:6a2, size:1032 [8.191012] kdump-tools[516]: validate_mem_section: Can't read mem_section array. [8.195497] kdump-tools[516]: get_mem_section: Could not validate mem_section. [8.197581] kdump-tools[516]: get_mm_sparsemem: Can't get the address of mem_section. [8.199601] kdump-tools[516]: makedumpfile Failed. [8.204346] kdump-tools[516]: * kdump-tools: makedumpfile failed, falling back to 'cp' And when skipping that, and just collecting the dmesg output, the same error reproduces: [8.369266] kdump-tools[513]: Starting kdump-tools: * running makedumpfile -c -d 31 /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171242/dump-incomplete [8.382379] kdump-tools[513]: mv: cannot stat '/var/crash/202006171242/dump-incomplete': No such file or directory [8.385529] kdump-tools[513]: * kdump-tools: saved vmcore in /var/crash/202006171242 [8.405479] kdump-tools[513]: * running makedumpfile --dump-dmesg /home/ubuntu/201909170743/vmcore.201909170743 /var/crash/202006171242/dmesg.202006171242 [8.43] kdump-tools[513]: readmem: Can't convert a virtual address(6a2) to physical address. [8.424872]
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
You're very welcome mfo, thanks for following this SRU in order to get that released soon =) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Committed Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Hey Guilherme, Thanks for the pointers and confirming these are not regressions, but known issues. :) -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Committed Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Also, ppc64/s390 are being tracked here: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1851663 It's a common issue, and difficult to debug (if we run tests locally, we can't reproduce and they succeeed). Regarding i386, we should remove tests for i386 in Eoan and Focal. Cheers, Guilherme -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Committed Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
The autopkgtests regressions are unrelated to this SRU. Sure enough: the patch is for arm64 only, but the archs failing are i386, ppc64el, and s390x. The "regressions" also happen with the version in -updates, in the same way as in -proposed. makedumpfile [eoan/i386] [1] Version TriggersDateDurationRequester Result 1:1.6.6-2ubuntu2... 2020-06-16 19:07:17 UTC 0h 05m 47s mfo faillog artifacts ♻ 1:1.6.6-2ubuntu2.1 ... 2020-06-16 11:51:34 UTC 0h 07m 23s mfo faillog artifacts ♻ makedumpfile [eoan/ppc64el] [2] Version TriggersDateDurationRequester Result 1:1.6.6-2ubuntu2... 2020-06-16 18:56:11 UTC 0h 06m 31s mfo faillog artifacts ♻ 1:1.6.6-2ubuntu2.1 ... 2020-06-16 11:47:27 UTC 0h 05m 22s mfo faillog artifacts ♻ makedumpfile [bionic/s390x] [3] Version TriggersDateDurationRequester Result 1:1.6.5-1ubuntu1~18.04.4... 2020-06-16 18:52:05 UTC 0h 03m 08s mfo faillog artifacts ♻ 1:1.6.5-1ubuntu1~18.04.5... 2020-06-16 11:46:00 UTC 0h 03m 06s mfo faillog artifacts ♻ [1] https://autopkgtest.ubuntu.com/packages/m/makedumpfile/eoan/i386 [2] https://autopkgtest.ubuntu.com/packages/m/makedumpfile/eoan/ppc64el [3] https://autopkgtest.ubuntu.com/packages/m/makedumpfile/bionic/s390x -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Committed Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to :
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
makedumpfile 1.6.5-1ubuntu1~18.04.5 Tags: verification-done-bionic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Committed Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Hello chenrongwen, or anyone else affected, Accepted makedumpfile into focal-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/makedumpfile/1:1.6.7-1ubuntu2.1 in a few hours, and then in the -proposed repository. Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- focal to verification-done-focal. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-focal. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. ** Changed in: makedumpfile (Ubuntu Focal) Status: In Progress => Fix Committed ** Tags added: verification-needed verification-needed-focal ** Changed in: makedumpfile (Ubuntu Eoan) Status: New => Fix Committed ** Tags added: verification-needed-eoan -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: Fix Committed Status in makedumpfile source package in Bionic: Fix Committed Status in makedumpfile source package in Eoan: Fix Committed Status in makedumpfile source package in Focal: Fix Committed Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe :
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Hi Jo, Eric, Eric, thanks for uploading to Groovy! (Sorry, I had made similar changes to groovy v2 debdiff -- no worries, but just wanted to let you know I checked those for groovy too, to not give you more trouble in helping here! :-) The changes have landed in Groovy, so I just uploaded to Focal/Eoan/Bionic/Xenial. cheers, Mauricio ** Changed in: makedumpfile (Ubuntu Focal) Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: New Status in makedumpfile source package in Bionic: New Status in makedumpfile source package in Eoan: New Status in makedumpfile source package in Focal: In Progress Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Package changed: linux (Debian) => makedumpfile (Debian) ** No longer affects: linux (Ubuntu) ** No longer affects: linux (Ubuntu Xenial) ** No longer affects: linux (Ubuntu Bionic) ** No longer affects: linux (Ubuntu Eoan) ** No longer affects: linux (Ubuntu Focal) ** No longer affects: linux (Ubuntu Groovy) ** Changed in: makedumpfile (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: makedumpfile (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: makedumpfile (Ubuntu Eoan) Importance: Undecided => Medium ** Changed in: makedumpfile (Ubuntu Focal) Importance: Undecided => Medium -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in makedumpfile package in Ubuntu: Fix Released Status in makedumpfile source package in Xenial: New Status in makedumpfile source package in Bionic: New Status in makedumpfile source package in Eoan: New Status in makedumpfile source package in Focal: New Status in makedumpfile source package in Groovy: Fix Released Status in makedumpfile package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
This bug was fixed in the package makedumpfile - 1:1.6.7-1ubuntu3 --- makedumpfile (1:1.6.7-1ubuntu3) groovy; urgency=medium * d/p/0003-align_PMD_SECTION_MASK_with_PHYS_MASK.patch (LP: #1869465) - Fixing arm64 systems makedumpfile looping forever exhausting all memory when filtering kernel core. -- Ioanna Alifieraki Thu, 04 Jun 2020 14:36:01 +0100 ** Changed in: makedumpfile (Ubuntu Groovy) Status: In Progress => Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in makedumpfile package in Ubuntu: Fix Released Status in linux source package in Xenial: In Progress Status in makedumpfile source package in Xenial: New Status in linux source package in Bionic: In Progress Status in makedumpfile source package in Bionic: New Status in linux source package in Eoan: In Progress Status in makedumpfile source package in Eoan: New Status in linux source package in Focal: In Progress Status in makedumpfile source package in Focal: New Status in linux source package in Groovy: In Progress Status in makedumpfile source package in Groovy: Fix Released Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
The attachment "lp1869465_groovy.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team. [This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.] -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in makedumpfile package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in makedumpfile source package in Xenial: New Status in linux source package in Bionic: In Progress Status in makedumpfile source package in Bionic: New Status in linux source package in Eoan: In Progress Status in makedumpfile source package in Eoan: New Status in linux source package in Focal: In Progress Status in makedumpfile source package in Focal: New Status in linux source package in Groovy: In Progress Status in makedumpfile source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Also affects: makedumpfile (Ubuntu) Importance: Undecided Status: New ** Changed in: makedumpfile (Ubuntu Groovy) Importance: Undecided => Medium ** Changed in: makedumpfile (Ubuntu Groovy) Status: New => In Progress ** Changed in: makedumpfile (Ubuntu Groovy) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Tags removed: sts-sponsor-mfo-and-slashd ** Tags added: sts-sponsor-mfo -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in makedumpfile package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in makedumpfile source package in Xenial: New Status in linux source package in Bionic: In Progress Status in makedumpfile source package in Bionic: New Status in linux source package in Eoan: In Progress Status in makedumpfile source package in Eoan: New Status in linux source package in Focal: In Progress Status in makedumpfile source package in Focal: New Status in linux source package in Groovy: In Progress Status in makedumpfile source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
[Groovy sponsor] Nitpicking: * Renamed "align_PMD_SECTION_MASK_with_PHYS_MASK.patch" 0003-align_PMD_SECTION_MASK_with_PHYS_MASK.patch to match his current little friend "0002-adapt-makefile-to-debian.patch" * Added more detail in the debian/changelog to ease future reference in a simple look: * d/p/0003-align_PMD_SECTION_MASK_with_PHYS_MASK.patch (LP: #1869465) + - Fixing arm64 systems makedumpfile looping forever exhausting + all memory when filtering kernel core. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in makedumpfile package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in makedumpfile source package in Xenial: New Status in linux source package in Bionic: In Progress Status in makedumpfile source package in Bionic: New Status in linux source package in Eoan: In Progress Status in makedumpfile source package in Eoan: New Status in linux source package in Focal: In Progress Status in makedumpfile source package in Focal: New Status in linux source package in Groovy: In Progress Status in makedumpfile source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
[Groovy sponsor] Nitpicking: * Renamed "align_PMD_SECTION_MASK_with_PHYS_MASK.patch" 0003-align_PMD_SECTION_MASK_with_PHYS_MASK.patch to match his current little friend "0002-adapt-makefile-to-debian.patch" * Added more detail in the debian/changelog to ease future reference in a simple look: * d/p/align_PMD_SECTION_MASK_with_PHYS_MASK.patch (LP: #1869465) + - Fixing arm64 systems makedumpfile looping forever exhausting + all memory when filtering kernel core. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in makedumpfile package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in makedumpfile source package in Xenial: New Status in linux source package in Bionic: In Progress Status in makedumpfile source package in Bionic: New Status in linux source package in Eoan: In Progress Status in makedumpfile source package in Eoan: New Status in linux source package in Focal: In Progress Status in makedumpfile source package in Focal: New Status in linux source package in Groovy: In Progress Status in makedumpfile source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
[Groovy sponsor] Nitpicking: * Renamed "align_PMD_SECTION_MASK_with_PHYS_MASK.patch" 0003-align_PMD_SECTION_MASK_with_PHYS_MASK.patch which his little current friend "0002-adapt-makefile-to-debian.patch" * Added more detail in the debian/changelog to ease future reference in a simple look: * d/p/align_PMD_SECTION_MASK_with_PHYS_MASK.patch (LP: #1869465) +- Fixing arm64 systems makedumpfile looping forever exhausting + all memory when filtering kernel core. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in makedumpfile package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in makedumpfile source package in Xenial: New Status in linux source package in Bionic: In Progress Status in makedumpfile source package in Bionic: New Status in linux source package in Eoan: In Progress Status in makedumpfile source package in Eoan: New Status in linux source package in Focal: In Progress Status in makedumpfile source package in Focal: New Status in linux source package in Groovy: In Progress Status in makedumpfile source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Disregard my last comment (#15) ... I was confused for a second between : #define PHYS_MASK ((1UL << PHYS_MASK_SHIFT) - 1) #define PMD_SECTION_MASK((1UL << 40) - 1) so PMD_SECTION_MASK fix is not found in debian yet. I'll sponsor the debdiff over the weekend. - Eric -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
[Groovy sponsoring] At first glance, It seems to be a good candidate for a 'sync' from debian here. https://wiki.ubuntu.com/UbuntuDevelopment/Merging#Check_if_its_a_merge_or_a_sync https://wiki.ubuntu.com/SyncRequestProcess The fix seems to be found in makedumpfile 'unstable' makedumpfile (1:1.6.7-2) # arch/arm64.c 84 #define PMD_SECTION_MASK((1UL << 40) - 1) - Eric -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Patch added: "lp1869465_eoan_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380771/+files/lp1869465_eoan_v2.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Patch added: "lp1869465_groovy_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380769/+files/lp1869465_groovy_v2.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Tags removed: sts-sponsor-mfo ** Tags added: sts-sponsor-mfo-and-slashd -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Patch added: "lp1869465_bionic_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380772/+files/lp1869465_bionic_v2.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Patch added: "lp1869465_xenial_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380773/+files/lp1869465_xenial_v2.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Patch added: "lp1869465_focal_v2.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380770/+files/lp1869465_focal_v2.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Hi Jo, Thanks for the debdiffs! The contents look good to me (versioning, dep3 headers) except that the patch sequence number is missing, and the changelog lacks a brief description of it. I just fixed those minor things up, and verified all debdiffs apply cleanly, quilt push -a applies cleanly, and quilt series show the sequence numbers correctly. Attaching the new 'v2' debdiffs. The current status of upload queues, pending SRUs/ -proposed pockets, block-proposed- tags, is all good -- no makedumpfile uploads in progress. This should be good to go. I'll ask a coredev for sponsorship to groovy, and once it's there, I can sponsor for the stable releases. cheers, Mauricio -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Changed in: linux (Debian) Status: Unknown => New -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Tags added: patch -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: Unknown Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Tags added: sts-sponsor-mfo ** Changed in: linux (Ubuntu Xenial) Status: New => In Progress ** Changed in: linux (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Xenial) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: linux (Ubuntu Bionic) Status: Confirmed => In Progress ** Changed in: linux (Ubuntu Eoan) Status: New => In Progress ** Changed in: linux (Ubuntu Eoan) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Eoan) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: linux (Ubuntu Focal) Status: New => In Progress ** Changed in: linux (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Focal) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: linux (Ubuntu Groovy) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: Unknown Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Debdiff for Bionic ** Patch added: "lp1869465_bionic.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380403/+files/lp1869465_bionic.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: Unknown Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Debdiff for Eoan ** Patch added: "lp1869465_eoan.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380402/+files/lp1869465_eoan.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: Unknown Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Debdiff for Focal ** Patch added: "lp1869465_focal.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380401/+files/lp1869465_focal.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: Unknown Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Debdiff for Xenial ** Patch added: "lp1869465_xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380404/+files/lp1869465_xenial.debdiff ** Tags added: sts -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: Unknown Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Debdiff for Groovy ** Also affects: linux (Ubuntu Groovy) Importance: Medium Assignee: Ioanna Alifieraki (joalif) Status: Confirmed ** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Eoan) Importance: Undecided Status: New ** Patch added: "lp1869465_groovy.debdiff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+attachment/5380399/+files/lp1869465_groovy.debdiff -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in linux source package in Bionic: In Progress Status in linux source package in Eoan: In Progress Status in linux source package in Focal: In Progress Status in linux source package in Groovy: In Progress Status in linux package in Debian: Unknown Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Bug watch added: Debian Bug tracker #96 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96 ** Also affects: linux (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=96 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: Confirmed Status in linux package in Debian: Unknown Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Description changed: + [Impact] + + On some arm systems makedumpfile fails to translate virtual to physical addresses properly. + This may result in makedumpfile looping forever exhausting + all memory, or translating a virtual address to an invalid physical address + and then failing and falling back to cp. + The reason it cannot resolve some addresses is because the PMD mask is wrong. + When physical address mask allows up to 48bits pmd mask should allow the + same, currently pmd mask is set to 40bits (see commit [1]). + + Commit [1] fixes this bug. + + [Test Case] + + To hit this bug you need a system that needs physical addresses over 1TB. + This may be either because you have a lot + of memory or because the firmware mapped some memory above 1TB for some + reason [1]. + + A user hit this bug because firmware mapped memory above 1TB and provided a + dump so I could reproduce the bug when running makedumpfile on the dump. + + [Regression Potential] + + This commit changes the PMD_SECTION_MASK for arm64. So any regression potential + would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation + from virtual to physical addresses and therefore any regression would happen during + this process. + + [Other] + + [1] + https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b + + When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: Confirmed Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Changed in: linux (Ubuntu) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Bionic) Status: New => Confirmed ** Changed in: linux (Ubuntu Bionic) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: linux (Ubuntu) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => Medium -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: Confirmed Status in linux source package in Bionic: Confirmed Bug description: When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Thanks for taking the time to report this bug and helping to make Ubuntu better. We appreciate the difficulties you are facing, but this appears to be a "regular" (non-security) bug. I have unmarked it as a security issue since this bug does not show evidence of allowing attackers to cross privilege boundaries nor directly cause loss of data/privacy. Please feel free to report any other bugs you may find. ** Information type changed from Public Security to Public -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: Confirmed Bug description: When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
Here is the capture kernel's log: [0.00] Booting Linux on physical CPU 0x1f0200 [0x481fd010] [0.00] Linux version 4.15.0-91-generic (buildd@bos02-arm64-019) (gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)) #92-Ubuntu SMP Fri Feb 28 11:10:16 UTC 2020 (Ubuntu 4.15.0-91.92-generic 4.15.18) [0.00] efi: Getting EFI parameters from FDT: [0.00] efi: EFI v2.70 by EDK II [0.00] efi: ACPI 2.0=0x2057 SMBIOS 3.0=0x204e MEMATTR=0x23e32018 ESRT=0x23e77798 [0.00] esrt: Reserving ESRT space from 0x23e77798 to 0x23e777d0. [0.00] Reserving 5KB of memory at 0x7fffe000 for elfcorehdr [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x2057 24 (v02 HISI ) [0.00] ACPI: XSDT 0x2056 AC (v01 HISI HIP08 0113) [0.00] ACPI: FACP 0x2004 000114 (v06 HISI HIP08 HISI 20151124) [0.00] ACPI: DSDT 0x1FDC 00CFCC (v02 HISI HIP08 INTL 20181213) [0.00] ACPI: PCCT 0x2055 8A (v01 HISI HIP08 HISI 20151124) [0.00] ACPI: SSDT 0x2054 00E56A (v02 HISI HIP07 INTL 20181213) [0.00] ACPI: BERT 0x2049 30 (v01 HISI HIP08 HISI 20151124) [0.00] ACPI: HEST 0x2047 00058C (v01 HISI HIP08 HISI 20151124) [0.00] ACPI: ERST 0x2043 000230 (v01 HISI HIP08 HISI 20151124) [0.00] ACPI: EINJ 0x2042 000170 (v01 HISI HIP08 HISI 20151124) [0.00] ACPI: GTDT 0x2002 7C (v02 HISI HIP08 HISI 20151124) [0.00] ACPI: SDEI 0x1FE2 30 (v01 HISI HIP08 HISI 20151124) [0.00] ACPI: MCFG 0x1FE1 3C (v01 HISI HIP08 HISI 20151124) [0.00] ACPI: SLIT 0x1FE0 30 (v01 HISI HIP08 0001 HISI 20151124) [0.00] ACPI: SPCR 0x1FDF 50 (v02 HISI HIP08 HISI 20151124) [0.00] ACPI: SRAT 0x1FDE 000540 (v03 HISI HIP08 HISI 20151124) [0.00] ACPI: APIC 0x1FDD 00146C (v04 HISI HIP08 HISI 20151124) [0.00] ACPI: IORT 0x1FDB 001060 (v00 HISI HIP08 INTL 20181213) [0.00] ACPI: PPTT 0x1F8E 002130 (v01 HISI HIP08 HISI 20151124) [0.00] ACPI: SPMI 0x1F8D 41 (v05 HISI HIP08 HISI 20151124) [0.00] ACPI: SPCR: console: uart,mmio,0x3f2f8,115200 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x18 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x180100 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x180200 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x180300 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x19 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x190100 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x190200 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x190300 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1a -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1a0100 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1a0200 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1a0300 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1b -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1b0100 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1b0200 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1b0300 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1c -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1c0100 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1c0200 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1c0300 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1d -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1d0100 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1d0200 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1d0300 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1e -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1e0100 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1e0200 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1e0300 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1f -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1f0100 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1f0200 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 0 -> MPIDR 0x1f0300 -> Node 0 [0.00] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x38 -> Node 1 [0.00] ACPI: NUMA: SRAT: PXM 1 -> MPIDR 0x380100
