Download microcode proposals

Gerry Houlder gerry.houlder at seagate.com
Tue Jun 24 15:10:28 PDT 2014


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

OK, there are several different behaviors in existence. I presume all have
existed for at least 10 years. Perhaps we have learned from this that good
host download implementations do not change the indicated fields and
therefore they don't notice the difference between the different
implementations. Perhaps we should not be agonizing over this detail.
It seems that the most "universally acceptable" rule is that a device
server may terminate a download command when fields change between download
commands in the same sequence with "appropriate sense data". Alternatively,
a list of several appropriate sense data combinations could be listed.
On Tue, Jun 24, 2014 at 4:18 PM, Bill Martin-SSI <
bill.martin at ssi.samsung.com> wrote:
>  Jim:
>
>
>
> My proposals do not apply to a change in mode or MODE SPECIFIC field that
> go back to a zero offset.
>
>
>
> Bill Martin
>
> SSD I/O Standards
>
> Samsung Semiconductor, Inc.
>
> Cell (408) 499-1839
>
>
>
>
>
>
>
> *From:* James C Hatfield [mailto:james.c.hatfield at seagate.com]
> *Sent:* Tuesday, June 24, 2014 2:16 PM
> *To:* Bill Martin-SSI
> *Cc:* Kevin D Butt <kdbutt at us.ibm.com> (kdbutt at us.ibm.com); Gerry Houlder
> (gerry.houlder at seagate.com); Ballard, Curtis C (HP Storage) (
> curtis.ballard at hp.com); T10 Reflector; Richard Deglin-SSI
> *Subject:* Re: Download microcode proposals
>
>
>
> Bill (and others),
>
>
>
> I should point out that ACS-3 defines different behaviour for one case.
>
>
>
> ACS-3 requires that (if a a new download is started from the beginning,
> but with a different mode) the previous download in process is cancelled
> and the new download mode begins as if nothing bad happened. This is not a
> reported error.
>
>
>
> Note, that if the mode changes and the buffer offset is non-zero (and
> consecutive from the previous segment), this is an error for ATA also.
>
>
>  Thank You !!!
> -----------------------------------------------------------------
> Jim Hatfield
> Seagate Technology LLC
>    e-mail:  James.C.Hatfield at seagate.com
>    s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
>    voice:  720-684-2120
>    fax....: 720-684-2711
>    cell...: 720-771-8914
>
>
>
> On Tue, Jun 24, 2014 at 3:06 PM, Bill Martin-SSI <
> bill.martin at ssi.samsung.com> wrote:
>
> There were a number of comments on 14-121r1 and 14-150r0. This email
> attempts to summarize the responses and is an attempt to gain consensus
> prior to the next T10 meeting.
>
>
>
> 1)	  On the changing the MODE field in subsequent downloads:
>
> a.	   Seagate – declare an error if the MODE field changes from what
> was sent in the first segment, with an ASC of INVALID FIELD IN CDB;
>
> b.	  HP – MODE field changes for the last download for a download
> sequence and this MODE determines the activation method – no error
> generated for changes in the MODE field between segments; and
>
> c.	   IBM – would be acceptable with “may terminate” with an ASC
of COMMAND
> SEQUENCE ERROR;
>
> 2)	  On the MODE SPECIFIC field in different segments:
>
> a.	   Seagate – Capture the MODE SPECIFIC on the first download with
> MODE 0Dh and error if it changes;
>
> b.	  HP – did not address this issue; and
>
> c.	   IBM – use the value in the last segment and ignore the value in
> other segments with no error generated.
>
>
>
> There are some significant differences in this list where one
> implementation generates an error where another would have problems with an
> error being generated. Is there some middle ground that would allow
> application clients to know how a device server will respond?
>
>
>
> Thanks for any input,
>
>
>
> Bill Martin
>
> SSD I/O Standards
>
> Samsung Semiconductor, Inc.
>
> Cell (408) 499-1839
>
>
>
>
>
>
>



More information about the T10 mailing list