One problem with this requirement is that it was assumed
that the particular SBP-2 implementation to be used
would not have any information about 1284.4 - specific
requirements for FIFO processing of outbound/inbound
ORBs. Unless the SBP-2 layer software interface allows
this type of option to be specified for a particular login.
This may not be a problem for a target if the target-side
1284.4 implementation provides its own SBP-2 fetch
agent. I am not familiar with how SBP-2 implementations
are being designed; whether they implement "internal"
fetch agents, or do they support "external" fetch agents
for clients with special ORB processing requirements?
> -----Original Message-----
> From: Fumio Nagasaka [SMTP:email@example.com]
> Sent: Sunday, December 07, 1997 12:35 AM
> To: 'firstname.lastname@example.org'; 'email@example.com'
> Cc: 'PJohansson'
> Subject: P1394> Re: SBP-2 Bidirectional ORB
> Through the 1394 PWG discussion, I *was* thinking "in order execution"
> linked list of ORBs is required for printing application. Now I think
> the target
> may skip ORB execution in some case, even in a printing application,
> multiple logical channel.
> PJohansson@aol.com writes:
> * Well, how does the initiator *know* that the target has no data? Use
> * timeout? No, I think that this would be an ill-advised
> * inefficient, too.
> I don't think the initiator knows the target has no data. And I do not
> the application layer in the target device know the transport layer
> IN-ORB request from the initiator. Thus if there is an input request
> other ORBs and the target does not have any data to reply, SBP-2
> layer would not decide whether the application is going to send data
> 10 msec later or after 10 minutes hard working.
> We at 1394 PWG found the higher layer in the protocol stack in the
> shall service multiple logical channels. Then, the target agent may
> ORBs and distribute them into each logical channel. Please see an
> Each logical channel shall consume ORBs in the queue. Even if a
> channel received an ORB which is not executable, other logical
> would be available.
> Actually when paper out, the printer does not print and it does not
> PCL commands. Then any ORB which is pointing print data will be
> However the initiator may send status request through an available
> channel. The initiator can get reason why the ORB is stalled. And if
> trouble is unrecoverable, then it may send *TASK_ABORT* to the target.
> The PWG printer profile for SBP-2 is defining logical channel field in
> block of the "Normal command block ORB" data structure.
> Fumio Nagasaka
> Epson Software Development Laboratory Inc.
> Tel +81 268 25 4111, Fax +81 268 25 4627
> E-mail to firstname.lastname@example.org
> -----Original Message-----
> From: PJohansson [SMTP:PJohansson@aol.com]
> Sent: Thursday, December 04, 1997 11:17 AM
> To: email@example.com; firstname.lastname@example.org
> Subject: Re: P1394> Re: SBP-2 Bidirectional ORB
> In a message dated 97-11-21 12:18:06 EST, email@example.com
> <<If the target device does not have any data to reply, when the
> initiator is
> keeping Out-ORB, In-ORB and Out-ORB, the target fetch agent will be
> stalled at
> second ORB and third ORB will not be consumed.>>
> This is a true statement ONLY if the target reports in-order execution
> in its
> configuration ROM. To keep things in perspective, all of the
> discussions of
> printers (of which I am aware) have assumed in-order execution.
> <<In this case, "AGENT_STATE" shall be ACTIVE at this moment. Thus if
> initiator try to ping DOORBELL, this write-transaction for DOORBELL is
> redundant. To overcome this state, the initiator need to write a value
> AGENT_RESET register to force "AGENT_STATE" to turn RESET state. Is
> this a
> normal job for this purpose?>>
> Well, how does the initiator *know* that the target has no data? Use a
> timeout? No, I think that this would be an ill-advised strategy---very
> inefficient, too.
> Better for the target to complete the second ORB in the example above
> indicate zero data transfer. It's then free to go on the the third
> Peter Johansson
> Congruent Software, Inc.
> 3998 Whittle Avenue
> Oakland, CA 94602
> (510) 531-5472
> (510) 531-2942 FAX
> << File: InOrbStalled.PDF >>