INVALID COMMAND OPERATION CODE

Elliott, Robert (Server Storage) Elliott at hp.com
Thu May 15 18:07:24 PDT 2008


* 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



More information about the T10 mailing list