GS> The problem we have is how to get the initiator to take any sort
GS> of recovery action. SBP-2 expects that this will be detected by
GS> some mechanism independent of the 'target' module. The expected
GS> mechanism is a timeout. At the May PWG 1394 meeting (?),
another
GS> mechanism of Bus Reset was suggested.
The Annex E of SBP-2 Specification Rev.4 is describing;
<<<
E.4 Status FIFO write request
When the target detects a missing acknowledgement after a write to an
initiator’s status FIFO, it should
take no error recovery actions. Any target resources allocated to the ORB
should be released by the
target. The initiator is expected to discover the error by means of a
higher-level mechanism, such as a
command time-out and to initiate appropriate error recovery. The nature of
the error recovery undertaken
by the initiator likely depends whether or not the target processes ORB’s
and returns their status in order,
but in any event is beyond the scope of this description.
>>>
I was missing this section when I sent previous e-mail.
In my idea, a print spooler in the initiator shall detect time out.
Then this initiator shall write AGENT_RESET register or RESET_START
register. Writing RESET_START register will cause the target
same effect as "power reset". In addition to, in this case,...
SBP-2 E.4 >Any target resources allocated to the ORB should be released by
thetarget.
...so, ORB_POINTER is unusable to examine the last ORB which
was consumed. Thus this initiator shall ask the target to report the last
ORB
address utilizing higher level command sounds like "TRANSPORT_I2T_ABORT".
-------
Fumio Nagasaka
Epson Software Development Laboratory Inc.
Tel +81 268 25 4111, Fax +81 268 25 4627
E-mail to nagasaka.fumio@exc.epson.co.jp
> -----Original Message-----
> From: Greg Shue [SMTP:gregs@sdd.hp.com]
> Sent: Wednesday, August 05, 1998 11:20 AM
> To: Nagasaka Fumio
> Cc: p1394@pwg.org
> Subject: Re: P1394> Revised PWG1394 Cmd Set
>
>
> 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
> ----------------------------------------------------------------