Task management handling changes (99-227r0)

Gene_Milligan at notes.seagate.com Gene_Milligan at notes.seagate.com
Tue Aug 17 06:59:30 PDT 1999


* From the T10 Reflector (t10 at t10.org), posted by:
* Gene_Milligan at notes.seagate.com
*
<<If a target does not have the resources to accept a SPI command
information unit and the TASK MANAGEMENT FLAGS field equals 00h the target
shall transfer all the bytes of the current SPI command information unit
but need not hold the transmitted information.>>

     Although this is not part of the change proposal it needed to be read.
If I understand the above, I think it should be changed to make clearer
what "hold" means. Two alternatives are: "If a target does not have the
resources to accept a SPI command information unit and the TASK
MANAGEMENT FLAGS field equals 00h the target shall transfer all the bytes
of the current SPI command information unit and shall abort the SPI command
information unit." or "If a target does not have the resources to accept a
SPI command information unit and the TASK MANAGEMENT FLAGS field equals 00h
the target shall transfer all the bytes of the current SPI command
information unit and shall discard the transmitted information."

     Again not part of the changed text <<If the initiator has more
commands to send to the target it shall wait for the next selection before
those remaining commands may be sent.>> should be changed to "If the
initiator has more commands to send to the target, the initiator shall wait
at least until the next selection before those remaining commands may be
sent."

Now the first part of the change. <<If the TASK MANAGEMENT FLAGS field is a
supported value not equal 00h the target shall perform the selected task
management function before accepting any further SPI information units. On
completion of a supported task management function the target shall go to a
BUS FREE phase. No status shall be reported for the task management
function.>>

     This wording seems to prohibit queuing and/or requires cracking the
information units as they are transferred. Such an impression should be
eliminated. In addition the last sentence conflicts with other requirements
of SCSI. For example the task function may generate the requirement to
inform other initiators that their commands have been aborted by another
initiator. I am not certain of what the change should be but perhaps: "If
the TASK MANAGEMENT FLAGS field is a supported value not equal 00h the
target shall perform the selected task management function before acting
upon any further SPI information units. On completion of a supported task
management function the target shall go to a BUS FREE phase. No status
shall be reported for the task management function to the source initiator
but a CHECK CONDITION may be established for other initiators."

<<If the target terminates a SPI L_Q/SPI command information unit pair it
shall have no effect on any other SPI L_Q/SPI command information unit pair
beyond those caused by any task management functions contained within the
last SPI L_Q/SPI command information unit pair.>>

     I think we have a problem with the word "terminate". If the pair were
terminated with a command complete and the command was a write it would
have an effect on a subsequent read. Is this paragraph attempting to
address rejected pairs or executed pairs?

<<g) after a CLEAR ACA task mangement function is successfully received by
a target;>>

     Why should this be in the "shall expect" bus free category rather than
the "may expect"?

     In addition "management" is miss-spelled.

<<On receipt of a CLEAR ACA message the task manager shall go to the BUS
FREE phase following the successful receipt of the ABORT TASK SET
message.>>

     Why? This is in violation of SPI-2.

Gene


*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org






More information about the T10 mailing list