P1394 Mail Archive: Re: P1394> Revised PWG1394 Cmd Set

Re: P1394> Revised PWG1394 Cmd Set

Greg Shue (gregs@sdd.hp.com)
Tue, 4 Aug 1998 19:20:16 -0700 (PDT)

Fumio Nagasaka wrote:
>
> Greg Shue wrote:
> >
> >Fumio Nagasaka wrote:
> >
> >> 3.1. TRANSPORT_I2T_ABORT
> >> An initiator requests a target to stop ORB fetching,
> >> and solicits the target to reply STATUS block when
> >> the last ORB had been executed.
> >
> >I probably don't understand this one.
> >
> > Since we're using the UNORDERED model, all the ORBs on the
> > task list have been fetched by the target as soon as they
> > are placed on it. There is no point to issuing this command.
> >
> > This command would really need to be issued as a vendor-specific
> > Management Agent command, since it needs to be executed
> > asynchronously to the two ordered execution queues or
> > else a third queue needs to be defined.
> >
> > Using the ABORT TASK management function defined by SBP-2
> > beginning with the last task in the queue will do the same
> > thing if you want a queue-specific function.
> >
> >I don't think this provides any additional usefulness and
> >significantly changes the device model. What am I missing?
> >
> You are missing one point;
> Let me come back to your first note.
>
> Greg Shue wrote:
>
> GS>
> GS>Now, error recovery for when a target detects an ACK Timeout on a
> GS>Status FIFO write requires some special considerations. When
> GS>this condition happens the initiator and target may be
> GS>out-of-sync with each other, and the SBP-2 protocol does not
> GS>provide a mechanism for the initiator to determine that the
> GS>condition exists. The problem breaks down to two issues:
>
> SBP-2 protocol *does* provide a mechanism to show this status.
> An AGENT_STATE register has two bit to describe status.
>
> In this case "SBP-2 Specification Rev.4" is saying, the fetch agent
> shall transition to state DEAD. See page 62 "Transition Any:F5".
> The only way to recover from this state, the initiator need to
> write data on AGENT_RESET register.

Good point, but that status requires the intiator go look for it.
How will the initiator know to go look for it?

Here's another one for consideration:

Since a fetch agent may be processing transactions for multiple
Tasks simultaneously (since split-transactions), which ORB is
the ORB_POINTER supposed to reference? And when is it set?
SPB-2 Rev 4 doesn't say. It really is written to a sequential
execution model.

SBP-2 Rev 4, p 62 also says (just above State F5:) The fetch
agent __may__ also be instructed to transition to the dead
state as a result of an error in command execution detection by
the device server.

If the SBP-2 target driver provides a hook to transition the
fetch agent to the DEAD state at any point in time, and if the
ORB_POINTER value is provided in that interface, then we might be
able to use the ORB_POINTER register. Unfortunately, I'm not
sure if this functionality is a requirement.

> Your scenario cause an impression that the target device shall
> be responsible for recovery. However, SBP-2 specification requires
> the initiator to be responsible in this case.

I don't see it as the target is responsible for _recovery_, but
it is responsible for _detection_ and _indication_. A Bus Reset
by itself doesn't recover from the situation, it just indicates
that something is drastically wrong.

The problem we have is how to get the initiator to take any sort
of recovery action. SBP-2 expects that this will be detected by
some mechanism independent of the 'target' module. The expected
mechanism is a timeout. At the May PWG 1394 meeting (?), another
mechanism of Bus Reset was suggested.

Any other suggestions?

-- 
Greg Shue
Hewlett-Packard Company
All-in-One Division			        gregs@sdd.hp.com
----------------------------------------------------------------