Eric, thanks for looking into the testing failure.
I was discussing with Cascardo today, and he was able to spot quickly the
problem.
First, the reason "makedumpfile" test passed in ppc64el before was that the
test was skipped; Cascardo changed "makedumpfile" to be part of the called "big
packages"[0], in order the VMs used in the tests have more RAM. Now, the test
gets executed and fails if kernel version is >= 4.20.
The reason of the failure was that "makedumpfile" couldn't collect a
compressed dump, falling back to 'cp' - this led to the 'if' failure in
the test. The root cause is that kernel patch 4ffe713b7587 ("powerpc/mm:
Increase the max addressable memory to 2PB"), introduced in v4.20,
requires a counterpart in "makedumpfile", in the form of patch [1].
Without that, I was able to reproduce the problem locally:
$ makedumpfile -c -d 31 /proc/vmcore /var/crash/201908051539/dump-incomplete2
get_machdep_info_ppc64: Can't detect max_physmem_bits.
makedumpfile Failed.
When I've used kernel 4.18 in the same VM, I got:
$ makedumpfile -c -d 31 /proc/vmcore core.418
Copying data : [100.0 %] \ eta:
0s
The dumpfile is saved to core.418
The plan here according to Cascardo is to push makedumpfile 1.6.6 (already
containing the fix for the "physmem_bits" issue as well as my fix for this LP,
the retry/delay mechanism) to Eoan.
After that, in my understanding, we can move on with the SRU for Bionic/Disco.
Cheers,
Guilherme
[0] https://git.launchpad.net/~cascardo/autopkgtest-cloud/commit/?id=346b786925
[1] https://salsa.debian.org/debian/makedumpfile/commit/f349b51f
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1681909
Title:
kdump is not captured in remote host when kdump over ssh is configured
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
