INVALID COMMAND OPERATION CODE

Knight, Frederick Frederick.Knight at netapp.com
Fri May 16 07:34:01 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
Consider these SPC commands:
6.24 REPORT SUPPORTED OPERATION CODES command
Op code A3h with service action 0Ch
6.25 REPORT SUPPORTED TASK MANAGEMENT FUNCTIONS command
Op code A3H with service action 0Dh
6.26 REPORT TARGET PORT GROUPS command
Op code A3h with service action 0Ah
6.27 REPORT TIMESTAMP command
Op code A3h with service action 0Fh
So, if I support some of these COMMANDS, but not others of these
COMMANDS, then the unsupported COMMANDS should return "INVALID FIELD IN
CDB"?  Why do these COMMANDS (if not supported) not return "INVALID
COMMAND OPERATION CODE"?  Would it only return INVALID COMMAND OPERATION
CODE if I don't support any of these commands?	That seems inconsistent.
It seems like we've already started taking service action and op code
combinations and calling them COMMANDS.  Clarifying this may not be
simple.
	Fred Knight
	NetApp
-----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at hp.com] 
Sent: Thursday, May 15, 2008 9:07 PM
To: t10 at t10.org
Subject: RE: INVALID COMMAND OPERATION CODE
* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
1. I think the historical precedent is that only a bad OPERATION CODE
field provokes the INVALID COMMAND OPERATION CODE response.  INVALID
FIELD IN CDB is the correct response.  I don't think INVALID FIELD IN
PARAMETER LIST is ever correct.
This is the current wording in 4.3.1:
"If a logical unit receives a reserved CDB code value in a field other
than the OPERATION CODE field, then the logical unit shall terminate the
command with CHECK CONDITION status, with the sense key set to ILLEGAL
REQUEST, and the additional sense code set to INVALID FIELD IN CDB.
...
If a device server receives a CDB containing an operation code that is
invalid or not supported, the command shall be terminated with CHECK
CONDITION status, with the sense key set to ILLEGAL REQUEST, and the
additional sense code set to INVALID COMMAND OPERATION CODE."
2. Chapters 8 and 9 (well known logical units and security manager) have
some conflicting rules, however, in tables that have commands defined by
operation code/service combinations:
8.6/table 522 and 9/table 523.	These problems are all new to SPC-4.
For example, 8.6/table 522 say:
"If a command is received by the MANAGEMENT PROTOCOL well known logical
unit that is not listed in table 522, then the command shall be
terminated with CHECK CONDITION status, with the sense key set to
ILLEGAL REQUEST, and the additional sense code set to INVALID COMMAND
OPERATION CODE."
Table 522 includes two commands:
MANAGEMENT PROTOCOL IN	A3h/10h
MANAGEMENT PROTOCOL OUT A4h/10h
with this footnote:
"This command is defined by a combination of operation code and service
action. The operation code value is shown preceding the slash and the
service action value is shown after the slash."
which results in two conflicting "shall"s.
The simplest fix may be:
a) reword the text introducing the tables in chapters 8 and 9 to avoid
duplicate shalls:
"If a command ... that is not listed in table 522, then the command
shall be terminated as defined in 4.3.1."
b) change 4.3.1 to mention SERVICE ACTION field as an explicit example
causing INVALID FIELD IN CDB.
Also, add the words "or unsupported".  This sentence first appeared in
spc3r12, by 03-005r1 moving it from sam3r04)
"If a logical unit receives a reserved __or unsupported__ CDB code value
in a field other than the OPERATION CODE field __(e.g., a SERVICE ACTION
field)__, then ... additional sense code set to INVALID FIELD IN CDB."
---
Rob Elliott, HP Industry Standard Server Storage
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mike
Berhan
Sent: Thursday, May 08, 2008 2:25 PM
To: t10 at t10.org
Subject: INVALID COMMAND OPERATION CODE
* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
Regarding the return of INVALID COMMAND OPERATION CODE, SPC states:
"If a device server receives a CDB containing an operation code that is
invalid or not supported, the command shall be terminated with CHECK
CONDITION status, with the sense key set to ILLEGAL REQUEST, and the
additional sense code set to INVALID COMMAND OPERATION CODE."
I have looked at SPC for a precise definition as to what a drive should
respond with if it is sent an Operation Code / Service Action that it
does not support (perhaps it supports other service actions, just not
the one you are requesting).  In practice, I have seen quite a few
devices that return INVALID FIELD IN CDB or INVALID FIELD IN PARAMTER
LIST.  What I expected, however, was an INVALID COMMAND OPERATION CODE.
My assumption is based on the SPC specification which shows the
"Operation Code" as a combination of the opcode / service action such as
SPC-4 Table 75 (Commands for all device types).  Is my assumption
correct?
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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