Mike Christie wrote:
jeykholt@xxxxxxxxx wrote:+ * fnic_queuecommand + * Routine to send a scsi cdb + * Called with host_lock held and interrupts disabled. + */ +int fnic_queuecommand(struct scsi_cmnd *sc, void (*done)(struct scsi_cmnd *)) +{ + struct fc_lport *lp; + struct fc_rport *rport; + struct fnic_io_req *io_req; + struct fnic *fnic; + struct vnic_wq_copy *wq; + int ret; + u32 sg_count; + unsigned long flags; + + rport = starget_to_rport(scsi_target(sc->device)); + ret = fc_remote_port_chkready(rport); + if (ret) { + sc->result = ret; + done(sc); + return 0; + } + + lp = shost_priv(sc->device->host); + if (lp->state != LPORT_ST_READY || !(lp->link_status & FC_LINK_UP)) { + sc->result = DID_NO_CONNECT << 16;You should use SCSI_MLQUEUE_HOST_BUSY here, becuase we set the link status/state and then will block rports, if a io has passed the rport check then sees the updated state we will fail it when it should be requeued until the fc class decides what to do.
Are you sure ? I would assume that if you passed the chkready() test, but still don't have connectivity to the device, you should be failing it with a DID_NO_CONNECT. The chkready(), paired with the fc_remote_port_delete()/blocked luns, should cover the temporary losses of connectivity.
-- james s -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
