INVALID COMMAND OPERATION CODE

Knight, Frederick Frederick.Knight at netapp.com
Fri May 16 20:18:30 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
It appears that there isn't a consistent handling this across the whole
family of SCSI Specs and every use of service action.
In SPC4r14, if you look at these 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
in each of their command description sections, they are independent
commands.  There is a reference in each of the opening paragraphs for
these commands that refers to SCC which states that service actions
defined in SCC apply only to LUNs that report themselves as SCC device
types (the SCC error text in SCC also apply only to SCC device types).
If you look at the PR conflict table (in table 43), each of the above
commands have independent PR conflict status lines.  The only place I
can find in SPC where they are not referred to as independent commands
is in the informative (not normative) annex D.	I believe these are
intended to use the service action as an extension of the op code field
(creating a larger single op code). As such, these commands (and others
that are described like these are) should if not supported, return
INVALID COMMAND OPERATION CODE.
PR-OUT on the other hand (6.14) has one command description with
multiple service actions (much the way SCC does).  It is clearly
documented in the description for the PR-OUT command that unsupported
service actions should return INVALID FIELD IN CDB.  And I'm sure there
are other commands that use this model.
This is why I don't think this is a simple thing to solve in a single
generic way.  I think some cases of commands + service actions are
independent commands (the service action is an extension of the op code
field), and other cases of commands + service actions are not
independent commands, but rather they are sub actions of just the one
command.
	Fred Knight
-----Original Message-----
From: Sheffield, Bob [mailto:Bob.Sheffield at lsi.com] 
Sent: Friday, May 16, 2008 6:30 PM
To: George Penokie; Knight, Frederick
Cc: Elliott, Robert (Server Storage); t10 at t10.org
Subject: RE: INVALID COMMAND OPERATION CODE
SSC-2 subclause 7.5 READ POSITION command ...
If the device server does not implement the specified service action
code, then the command shall be terminated with CHECK CONDITION status.
The sense key shall be set to ILLEGAL REQUEST, and the additional sense
code shall be set to INVALID FIELD IN CDB.
...
Bob Sheffield
Engenio Storage Group
MegaRAID Architecture
LSI Logic Corporation
www.lsilogic.com/engenio
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of George
Penokie
Sent: Friday, May 16, 2008 1:26 PM
To: Knight, Frederick
Cc: Elliott, Robert (Server Storage); t10 at t10.org
Subject: Re: INVALID COMMAND OPERATION CODE
* From the T10 Reflector (t10 at t10.org), posted by:
* George Penokie <george at penokie.com>
*
Fred,
I do not agree with Rob. The action codes were intended to be extensions
to the op codes and as such if one is received that a logical does not
support it should fail with INVALID COMMAND OPERATION CODE. If that is
not clear then we need to change the standards to make it that way.
When I get back to work on Monday I will look at SCC-2 to see what we
say in that standard as it was the first to use action codes.
Bye for now,
George
Knight, Frederick wrote:
> * 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
>
>
>   
*
* 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