Logical unit reset and target reset
Andy Green
andy.green at oxsemi.com
Mon Apr 28 01:36:24 PDT 2003
Peter Johansson wrote:
> In comment 75, Rob Elliott touches upon a matter that I think has gone
> unnoticed since SBP-2 was first published.
>
> As presently written, an initiator that causes a logical unit reset or a
> target reset receives no individual indication for its own tasks that
> are aborted: the successful completion of the logical unit reset or the
> target reset is implicit indication that all of the initiator's tasks
> have been aborted. SBP also says that a unit attention condition is
> created for other affected initiators---but how do they discover this
> and also discover that their tasks have been aborted?
>
> I think new language to be added to SBP-3. It should make it clear that
> completion status shall be stored for tasks that belong to initiators
> other than the initiator that requested the logical unit reset or target
> reset. In this way, those other initiators become aware that their fetch
> agents are dead and their tasks aborted.
>
I quite agree; I think a lot of the procedure is implied by a search through SBP
and SAM, but it would have been nice to have step-by-step instructions all in
one place.
> I've excerpted the proposed modifications and attached them to this
> message. Since we propose to complete SBP-3 comment resolution at the
> T10 meeting in Nashua, please review as quickly as possible.
This seems reasonable, however what should the target do for initiators who have
empty task sets? I suspect some unit attention conditions are relevant to them,
e.g. MODE_PARAMETERS_CHANGED. I think the instructions should have one more step
to the effect of: "For empty task sets, the logical unit shall store unsolicited
status if enable, otherwise it shall hold a pending unit attention condition
which shall be notified to the initiator when the task set becomes non-empty"
This is the approach taken by the 911 (although I've never seen a host generate
this condition);
> I think it is unlikely that the proposed modifications will affect
> existing implementations since, to the best of my knowledge,
> contemporary SBP devices implement only a single initiator and task set
> model. If your company makes a product capable of multiple initiator
> login, please give very careful consideration to the changes suggested
>
As Eric pointed out, yes it will...
Andy
******************************************************
SBP-3 protocol for FireWire Mailing List
Unsubscribing:
send email to requests at isg.apple.com with subject "unsubscribe sbp3"
Set to Digest Mode:
send email to requests at isg.apple.com with subject "subscribe digest sbp3"
Help?:
send email to requests at isg.apple.com with subject "help"
******************************************************
More information about the T10
mailing list