FCP_RESP AND LOG PAGE FOR REQ_CONFIRM ERRORS

GFRAZIER at AUSVM6.VNET.IBM.COM GFRAZIER at AUSVM6.VNET.IBM.COM
Fri May 5 06:25:01 PDT 1995


After reading all the e-mail on this, such as Charles Binford's comment:

>Giles wrote in response to ......in response to...:
  >If the FCP_RESP was lost, the initiator would discover it after a ULP
  >timeout and it could then read the log to discover that the cached data
  >was lost. Again, this procedure uses existing SCSI-3 procedures--no
  >reinvention.

>Sounds good, but I haven't seen a standardized method of retrieving log
>information.  Data which is in a vendor specific format.  Maybe we should
>redirect our efforts to create a standard log page which keeps the last
>n sense buffers!

I think this is what we should do. More FCP IUs are only going to add more
microcode development and time, and add to the length of FCP.

As to the pages to be fixed, I think that all we need to do is to create
a log page which keeps a record of deferred errors as Charles suggested.
For other asynchronous events, the Informational Exceptions control
page should be sufficient since it lets the initiator set an interval timer
for repeating notifications of events and allows the initiator to specify
details on how to report asynchronous events.

For deferred errors, all that we need is to have a place where an initiator
ULP can look when it times out on a command without receiving an FCP_RESP
IU. This does not need to contain ALL the FCP_RESP IUs which have been
sent--only those which would have been sent with an FCP_RESP_REQ_CONFIRM.

I'll contact Mike Fitzpatrick about this as Tom Battle suggested in one of the
notes.
Giles Frazier
IBM Austin
gfrazier at ausvm6.vnet.ibm.com




More information about the T10 mailing list