INVALID COMMAND OPERATION CODE

Sheffield, Bob Bob.Sheffield at lsi.com
Fri May 16 15:30:04 PDT 2008


* From the T10 Reflector (t10 at t10.org), posted by:
* "Sheffield, Bob" <Bob.Sheffield at lsi.com>
*
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