James Smart wrote:
Christof Schmitt wrote:
On Wed, Oct 21, 2009 at 12:24:31PM -0400, James Smart wrote:
But - this process is a coordinated effort between the driver and the
upper layers, and where the driver doesn't get helped by the
transport (the blocked state) it had better mimic the return codes at
the different points, and perhaps more, so that bad things don't happen.
"mimic the return codes" refers to fc_remote_port_chkready? Like
returning DID_IMM_RETRY when the rport is going to be BLOCKED, but
fc_remote_port_delete did not run yet?
Yes
Although, now that I look at chkready again, I'm surprised it didn't
have one of Mike's TRANSPORT_DISRUPTED status's being returned.
We use DID_IMM_RETRY and do not use TRANSPORT_DISRUPTED in
fc_remote_port_chkready because it would count against the retries which
we do not want when we hit those state change races. I think
Andrew/qlogic hit something where during those race windows we could
exhaust all the retries.
--
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
