It seems like there's some race in the kernel when we try to delete_controller (nvme disconnect) right after the new nvme subsystem is connected. This results in a block subsystem left with lingering nvme devices which are not usable and which start to affect the nvmf suite. They also can't be removed either unless the kernel is rebooted. To workaround it make sure that we wait long enough for all of the subsystems to be in a sane state before we attempt to stress the connect<->disconnect path. Mitigates #2060. Signed-off-by: Michal Berger <michalx.berger@intel.com> Change-Id: I9299ecfc760e334504730aab6f19d338fad88081 Reviewed-on: https://review.spdk.io/gerrit/c/spdk/spdk/+/9059 Reviewed-by: Pawel Piatek <pawelx.piatek@intel.com> Reviewed-by: Tomasz Zawadzki <tomasz.zawadzki@intel.com> Reviewed-by: Jim Harris <james.r.harris@intel.com> Community-CI: Broadcom CI <spdk-ci.pdl@broadcom.com> Tested-by: SPDK CI Jenkins <sys_sgci@intel.com> |
||
---|---|---|
.. | ||
config | ||
lib | ||
applications.sh | ||
autotest_common.sh | ||
skipped_build_files.txt | ||
skipped_tests.txt |