> The kernel configuration, CONFIG_SCSI_SCAN_ASYNC, is still set. Please
> do not enable this kernel configuration for s390x.
>
> Background why you shall disable this option:
> 
> The long-term default "sync" is probably well-tested. Experiences with async
> are rare. To be more frank here, sync is also used by other Linux distributions
> on z. For s390, the defconfig as well as our other upstream kernel
> configurations have or will have this being set to sync (again).

The upstream defconfig value for this setting is pretty much exclusivly
=y on all architectures and specifically for s390 is =y:

    arch/s390/defconfig:CONFIG_SCSI_SCAN_ASYNC=y

Examining the RHEL based host system that runs our KVM instances on our
local z-series system, those have the option set to =y as well:

    [root@s2lp7 ~]# grep CONFIG_SCSI_SCAN_ASYNC -r /boot/config-3.10.0-123.20.1.el7_0.kvmibm.1*
    /boot/config-3.10.0-123.20.1.el7_0.kvmibm.12.s390x:CONFIG_SCSI_SCAN_ASYNC=y
    /boot/config-3.10.0-123.20.1.el7_0.kvmibm.12.s390x.kdump:CONFIG_SCSI_SCAN_ASYNC=y
    /boot/config-3.10.0-123.20.1.el7_0.kvmibm.15.s390x:CONFIG_SCSI_SCAN_ASYNC=y
    /boot/config-3.10.0-123.20.1.el7_0.kvmibm.15.s390x.kdump:CONFIG_SCSI_SCAN_ASYNC=y

Simiarly for the current debian s390x kernels:

    $ grep SCSI_SCAN_ASYNC X/boot/config-4.4.0-1-s390x
    CONFIG_SCSI_SCAN_ASYNC=y
    $

> Apart from testing, the reason why I suggest to change this setting goes back
> to a talk with the zfcp device driver maintainer. I stumbled over this
> setting as trying out FCP devices on a Debian s390 system. Tools are
> expecting that attached LUNs to an FCP device should be synchronously, that
> means, the requests should be synchronously processed by the FCP device and
> the SCSI layer on top. Asynchronous processing might cause problems in tools
> that expect synchronous behavior. Further, asynchronous handling makes it
> more harder to wait for the SCSI device becomes available (if it exists at
> all). Thus, tools have to actively wait for something to happen... and the
> worst thing is, that there is no tooling at all that waits for asynchronous
> processing to become completed (udevadm settle is useless here as there are
> no uevent for LUN attachment requests).

This is a misscharacterisation of the effect of this configuration option.
The option does not make device discovery asyncronous with respect to
userspace.

The primary consequence of enabling this option is that the system does
not wait the devices to be found before moving on to other cpu intensive
initialisation.  This improves boot time by allowing us to go ahead an
decompress the initrd in parallel with devices discovery utilising the
otherwise idle CPU.  Further, does it change the order in which discovered
devices are numbered or indeed reported to userspace via udev; at the
end of discovery the events announcing devices are emitted in the same
order they would have been in a synchronous scan.  But most important all
asynchonous discovery must complete before we start the first userspace
process (see wait_for_device_probe() in prepare_namespace()) rendering
it synchronous with respect to init.

Given this has been the default model for all architecture for some
year, the asynchronous path is by far the path most travelled and most
tested I am resistant to making s390x the only architecture that uses
the synchronous model.  Especially as it is likely to increase image
boot times.