Currently, zfcpdump-kernel in ubuntu is on-par with v4.9 sources, and it does successfully complete SCSI dump of Ubuntu 17.10 which itself uses v4.13.
Our kernel team has attempted to upgrade zfcpdump-kernel to v4.13 sources, however such a kernel fails to complete the SCSI dump. (see attached operating systems messages)
With v4.9 based zfcpdump-kernel the kernel dmesg are cleared very quickly, and zfcpdump programme starts executing from the zfcpdump initrd pretty much instantly.
You can check v4.13 build-log & package at https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+build/13538881
Direct URL to download the v4.13 zfcpdump-kernel is:
$ wget https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+build/13538881/+files/zfcpdump-kernel_4.13-0ubuntu1~rc2_s390x.deb
$ apt install ./zfcpdump-kernel_4.13-0ubuntu1~rc2_s390x.deb
After that use zipl to prepare a drive for a dump as usual, and perform the dump.
We have also tried v4.10 based on zesty (17.04) release, compiled with zesty toolchain, and similar failure was observed.
Are there any new measure that we should be taking to configure, compile, and successfully create a zfcpdump compatible kernel, based on upstream v4.10 or later kernels?
>> Please see
>> https:/
>> has been requested for reverse-proxy.
>
> We looked into the report: It looks like the initramfs with the zfcpdump
> user space is not detected for some reason.
We believe this maybe a regression in the upstream kernel in v4.10 and later.
Exactly the same unchanged zfcpdump initrd is detected correctly by the v4.09 kernel.
Note that the zfcpdump initrd is shipped by s390-tools package, whilst the kernel image is shipped separately by the zfcpdump-kernel package. Therefore the initrd is good and is loadable by v4.09 kernel but not v4.10 kernel.
Or vice versa, v4.09 and earlier are more graceful and are loading the buggy zfcpdump initrd, but v4.10+ doesn't.
Could there be some config options, or configurations missing from the zfcpdump config?
We are using z13 mainframe - does kernel try to use hw accel compression? but the kernel or the LPAR are misconfigured?
Can you commit any kernel engineers to debug this further to find a root cause?