INVALID COMMAND OPERATION CODE

George Penokie george at penokie.com
Fri May 16 12:26:08 PDT 2008


* 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



More information about the T10 mailing list