Comment 35 for bug 1681909

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