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...


SBP-3 protocol for FireWire Mailing List
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"

send email to requests at isg.apple.com with subject "help"

More information about the T10 mailing list