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 Triggers Date Duration Requester
Result
1:1.6.6-2ubuntu2 ... 2020-06-16 19:07:17 UTC 0h 05m
47s mfo fail log artifacts ♻
1:1.6.6-2ubuntu2.1 ... 2020-06-16 11:51:34 UTC 0h 07m
23s mfo fail log artifacts ♻
makedumpfile [eoan/ppc64el] [2]
Version Triggers Date Duration Requester
Result
1:1.6.6-2ubuntu2 ... 2020-06-16 18:56:11 UTC 0h 06m
31s mfo fail log artifacts ♻
1:1.6.6-2ubuntu2.1 ... 2020-06-16 11:47:27 UTC 0h 05m
22s mfo fail log artifacts ♻
makedumpfile [bionic/s390x] [3]
Version Triggers Date Duration Requester
Result
1:1.6.5-1ubuntu1~18.04.4 ... 2020-06-16 18:52:05 UTC
0h 03m 08s mfo fail log artifacts ♻
1:1.6.5-1ubuntu1~18.04.5 ... 2020-06-16 11:46:00 UTC
0h 03m 06s mfo fail log 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(ffff9e653690) to
physical address.
kdump-tools[646]: readmem: type_addr: 0, addr:ffff9e653690, 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
