99-179r1 comments and comments on comments

gop at us.ibm.com gop at us.ibm.com
Fri Jun 4 10:05:40 PDT 1999


* From the T10 Reflector (t10 at symbios.com), posted by:
* gop at us.ibm.com
*
So now that I have rev 7 of SPI-3 out I have been able to go through the all the
notes cluttering up my reader on 99-179r1, I will throw in my 2-cents (or should
I say 2 minutes) worth.

Going back to Jeff's note and looking over the list of commands that are
currently required to execute, I tried to list the commands and give a reason
why they should be allowed to execute. Here's what I came up with:

Inquiry - SCSI rules say it always executes.
Request Sense - Needed to return the progress indication.
Send Diagnostic - Needed to abort a self-test when immed was used to start off
the self test. (This could go away see below)
Log Sense - Used to get interim information from the self test log page before
the self test is complete. (I thought we were going to drop that option)
Report LUNs - Got me.
Start/Stop - Got me.

I think we could reduce the list down to Inquiry and Request Sense and not lose
any functionality assuming log sense is not used.

Jeff also put together a table relating foreground/background and
immediate/non-immediate interactions with aborting, polling, and response to new
commands. I did the same thing and came up with the following slightly different
table:

FG/BG      Immed/             How to abort                How to     New
Commands   Self-test
                non-immed                                          Poll
fails
FG            immed              Send Diag (100b)         RS           CC-Not
Ready      Deferred error
FG            non-immed        Abort Task message     RS           CC-Not Ready
CC
BG            immed              Send Diag (100b)         RS           process
Deferred error
BG            non-immed        Abort Task message     RS           process
CC

Look close; the only differences between immed and non-immed are how to report a
self-test failure and how to abort the self-test. Operationally they are the
same. So way not eliminate the immed function (Remember the reason we put the
immed in there in the first place was to do what we now are calling a background
operation). If we do this life gets simpler with no loss of functionality and we
do not have to spend endless hours arguing about how deferred errors should be
handled.

The next problem, pointed out by Ralph, was the statement 'When STPI is zero the
device server shall not return the PROGRESS INDICATION field.' I agree with
Ralph; you cannot make existing functions illegal. There is nothing wrong with
sending a Request Sense command with an STPI bit of zero. If that happens then
the target returns whatever information it has for sense data at that point in
time. This is true if it is doing a format, self-test, configuration, or any
other kind of command. The only problem with an application client doing that is
it may not get back what it thinks it should for sense data. Which is not a good
idea, but it cannot be made illegal. The wording needs to be changed to:

''When STPI is zero the device server may return the PROGRESS INDICATION field.'

As for Ralph question about if we should be using Request sense or something
else. I agree with Gene in that using Request Sense in this manner is nothing
more than an extension of it's existing function and is the best solution.

Now on to my issues:
-The model is being too explicit about what kinds of tests are being run and the
ordering of those tests. Why are 3 and only 3 listed, what if I my device only
does two or four or some other number. The way it is currently written it looks
like the 3 are a requirement and that it must be those defined 3. This is
especially true in the test sequence section where not only is 3 the number but
the specific order is called out. The list needs to be made into an example and
the ordering needs to be generic. The kind of wording I am talking about would
replace:

The self-tests and modes are invoked by the application client by issuing a SEND
DIAGNOSTICS command to the logical unitwith the FUNCTION CODE field set to the
appropriate value. The device server shall then set the initiating value in the
FUNCTION CODE field and set the SELF-TEST RESULTS VALUE field to be Fh in its
Self-test results log page, store the log page to non-volatile memory, and begin
the first self-test segment. After completing the first two self-test segments,
the device server shall change the value in the SELF-TEST RESULTS VALUE field to
be Eh, update the log page in non-volatile memory with this new value and begin
the third self-test segment. Only the SELF-TEST RESULTS VALUE field shall be
changed as a result of this update. If the self-test is being performed in
background mode, updating the log allows the application client to read the
Self-test Results log page to determine that the read/verify segment is in
progress.



With something like this:

The self-tests and modes are invoked by the application client by issuing a SEND
DIAGNOSTICS command to the logical unit with the FUNCTION CODE field set to the
appropriate value. The device server shall set the function code value into the
FUNCTION CODE field if the Self-test log page.

For each self-test segment the device server shall:

1-indicate the type of self-test being run in the SELF-TEST RESULTS VALUE field
of the Self-test results log page,

2-store the log page to non-volatile memory, and

3-begin the self-test.

Only the SELF-TEST RESULTS VALUE field shall be changed as a result of switching
between self-test segments. If the self-test is being performed in background
mode, updating the log allows the application client to read the Self-test
Results log page to determine that the read/verify segment is in progress.


-I would like to see added to the self-test results values a value for
Vendor-specific self-test in progress and Vendor-specific self-test failed.

-The statement: 'The EXTENDED SELF-TEST ROUTINE COMPLETION TIME field shall not
be changeable by the application client.' should be removed as that is standard
SCSI operation for mode pages and therefore true for all mode page fields.


Bye for now,
George Penokie

Dept PPV  114-2 N212
E-Mail:    gop at us.ibm.com
Internal:  553-5208
External: 507-253-5208   FAX: 507-253-2880


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





More information about the T10 mailing list