The problem is that if we are doing a scsi scan then the device goes
into recovery then we will wait for the recovery to complete. It waits
because scsi-ml will send inquiries or report luns and the queueing code
will have been blocked due to the host not being ready. However, if we
are in recovery and then a scan is started the scan will silently fail
and some devices will not be added.

It is easy to hit the problem where devices do not show up with
FC where we are doing tests that disrupt the target controllers.
When the controller is disruprted (reboot, or setting firmware, etc),
and we cause the dev loss tmo to fire then devices will be removed
Then when the problem has been fixed, the rport will be scanned and
devices should be added back. But if we cause another disruption before
scanning has started then devices will not get added back. If the problem
is not started until the scan is started then the devices will be added
back.

This patch fixes that problem by not failing scans when the host
is in recovery. We will let scsi-ml send the IO and let the queueing
and scsi error handling deal with it like is done if we went into
recovery while scanning.

For recovery cases where the host is being torn down then with the
patch we will still fail the scan since there is not point in scanning.

Signed-off-by: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>