diff options
author | James.Smart@Emulex.Com <James.Smart@Emulex.Com> | 2005-08-10 15:02:30 -0400 |
---|---|---|
committer | James Bottomley <jejb@mulgrave.(none)> | 2005-08-12 13:08:54 -0400 |
commit | ea84c3f74df646a0897e95c78147190517a751a9 (patch) | |
tree | ab04eda0ed5763908dfbb5803e44052e53607f40 /drivers | |
parent | f888ba3ce77c66bece3d804caf7d559838209a4a (diff) |
[SCSI] lpfc driver 8.0.30 : dev_loss and nodev timeouts
Fix handling of the dev_loss and nodev timeouts.
Symptoms: when remote port disappears for a period of time longer then
either nodev_tmo or dev_loss_tmo, the lpfc driver worker thread will
stall removing that remote port.
Cause: removing remote port involves un-blocking and sync-ing
corresponding block device queue. But corresponding node in the lpfc
driver is still in the NPR(?node port recovery?) state and mid-layer
gets SCSI_MLQUEUE_HOST_BUSY as a return value when it is trying to call
queuecommand() with command for that node (AKA remote port)
Fix: Instead of returning SCSI_MLQUEUE_HOST_BUS from queuecommand() for
nodes in NPR states complete it with retry-able error code DID_BUS_BUSY
Signed-off-by: James Smart <James.Smart@emulex.com>
Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
Diffstat (limited to 'drivers')
-rw-r--r-- | drivers/scsi/lpfc/lpfc_scsi.c | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/drivers/scsi/lpfc/lpfc_scsi.c b/drivers/scsi/lpfc/lpfc_scsi.c index 15e747faaa5f..4be506a33a2e 100644 --- a/drivers/scsi/lpfc/lpfc_scsi.c +++ b/drivers/scsi/lpfc/lpfc_scsi.c | |||
@@ -753,6 +753,10 @@ lpfc_queuecommand(struct scsi_cmnd *cmnd, void (*done) (struct scsi_cmnd *)) | |||
753 | cmnd->result = ScsiResult(DID_NO_CONNECT, 0); | 753 | cmnd->result = ScsiResult(DID_NO_CONNECT, 0); |
754 | goto out_fail_command; | 754 | goto out_fail_command; |
755 | } | 755 | } |
756 | else if (ndlp->nlp_state == NLP_STE_NPR_NODE) { | ||
757 | cmnd->result = ScsiResult(DID_BUS_BUSY, 0); | ||
758 | goto out_fail_command; | ||
759 | } | ||
756 | /* | 760 | /* |
757 | * The device is most likely recovered and the driver | 761 | * The device is most likely recovered and the driver |
758 | * needs a bit more time to finish. Ask the midlayer | 762 | * needs a bit more time to finish. Ask the midlayer |