James Smart wrote:
> Background:
> The states, in the transport are:
> event state
> --------------------------------
> n/a running
> lose connectivity blocked
> fastfail timeout still blocked, but with fastfail indicator
My patch changed this one. When this times out, I unblock the queue.
> dev_loss timeout unblocked/removed
>
> Question:
>
> The chkready helper in the transport catches race conditions where the
> block is being put in place, but queuecommand is running on another cpu,
> thus returning DID_IMM_RETRY.
>
> Your patch is updating chkready to look for the case when fastfail has
> fired, and returning DID_TRANSPORT_FASTFAIL ? Why ? The request
> queue would be blocked so there should be no call to queuecommand that
> would fall into this category - unless you are assuming that fastfail
> timeout is so fast that it could fall into the same race condition as
> blocked.
In the patch, when the fast IO fail timer fires, I unblock the queues.
+ rport->fast_io_fail_timeout = 1;
i->f->terminate_rport_io(rport);
+ scsi_target_unblock(&rport->dev);
At that time IO would be queued on drivers and would hit that test and
be failed. New IO would also be failed upwards by that check.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
