Download microcode proposals

Gerry Houlder gerry.houlder at seagate.com
Fri Jun 6 08:10:00 PDT 2014


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1406060_f.htm">HTML-formatted message</a>

Hi Bill,
I reviewed 14-150r0 and 14-121r1 and have these comments:
(a) The text in 14-150r0 lumps download options 07h and 0Eh in with option
0Dh in describing the error case. This is incorrect. Options 07h and 0Eh
always requires the MODE SPECIFIC field to be zero (i.e., the field is
reserved) just like all of the other download options, so these cases
should always result in ILLEGAL REQUEST sense key with INVALID FIELD IN CDB
additional sense if that field is ever non-zero.
(b) I verified that Seagate products remember the MODE SPECIFIC field
setting (for option 0Dh) on the first download command in a sequence (i.e.,
when the BUFFER OFFSET is zero) and expect further download commands in the
same sequence to match that MODE SPECIFIC setting. If a further command
doesn't match the MODE SPECIFIC setting, then the command is rejected with
ILLEGAL REQUEST sense key and INVALID FIELD IN CDB additional sense code.
Seagate prefers using ILLEGAL REQUEST sense data to indicate that the
command is being discarded but any previously accepted download segments
are preserved, meaning that a correct download command resuming the
sequence is all that is needed for recovery. In most of the cases when
COMMAND SEQUENCE ERROR is reported, Seagate drives discard any previously
received download segments and expect the initiator to start over again
|from the beginning.
(c) Since the error situation described in 14-150 should only occur in
download option 0Dh (all other cases are covered by our existing rule about
reserved fields), then i prefer  error code response description to be in
the location indicated in proposal 14-121r1, not in the location indicated
in 14-150.
On Thu, Jun 5, 2014 at 4:10 PM, Bill Martin-SSI <bill.martin at ssi.samsung.com
> wrote:
>  As you may remember, I presented a proposed clarification of download
> microcode at the last T10 plenary meeting week. This was 14-121r1. There
> was agreement to review what products are currently doing in the case
> described.
>
>
>
> I have posted another proposal 14-150r0 with some additional
> clarifications to the download microcode operation. Please review this
> proposal to determine what your products currently do, so that we may
> complete these actions at the T10 plenary meeting in July in Colorado
> Springs.
>
>
>
> Thanks,
>
>
>
> Bill Martin
>
> SSD I/O Standards
>
> Samsung Semiconductor, Inc.
>
> Cell (408) 499-1839
>
>
>
>
>



More information about the T10 mailing list