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 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.
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-incomplete 2 info_ppc64: Can't detect max_physmem_bits.
get_machdep_
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 /salsa. debian. org/debian/ makedumpfile/ commit/ f349b51f
[1] https:/