76e4e12ff2
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> |
||
|---|---|---|
| .. | ||
| acpi | ||
| asm-generic | ||
| crypto | ||
| drm | ||
| keys | ||
| linux | ||
| math-emu | ||
| media | ||
| mtd | ||
| net | ||
| pcmcia | ||
| rdma | ||
| rxrpc | ||
| scsi | ||
| sound | ||
| target | ||
| trace | ||
| video | ||
| xen | ||
| Kbuild | ||