From alvin.cox at seagate.com Wed Jun 1 12:41:19 2011 From: alvin.cox at seagate.com (Alvin Cox) Date: Wed, 1 Jun 2011 14:41:19 -0500 Subject: Reminder: SAS PHY WG conference call, 10:00 am CDT, June 2, 2011 Message-ID: Formatted message: HTML-formatted message Agenda: AC coupling capacitor requirements SAS-3 AC coupling requirements SSC requirements: How much SSC is needed? Connector updates Channel analysis updates SAS-3 Electrical Spec (11-221r2 Formatted message: HTML-formatted message Hello all, SBC-3 draft revision 27 has been posted and is available at http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r27.pdf. Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com From George.Penokie at lsi.com Thu Jun 2 14:48:55 2011 From: George.Penokie at lsi.com (Penokie, George) Date: Thu, 2 Jun 2011 15:48:55 -0600 Subject: T10 Document Number Assigned (T10/11-036r5) Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * "Penokie, George" * A new version of the transmitter training proposal (11-036r5) has been posted. It includes the following changes. Revision 5 - Accepted the markups indicating changes from revision 4 that were made to the new sections. Added the following: a) made editorial fixes requested on the 5/25 transmitter training conference call; b) added a section that describes the phy's transmitter initial conditions; c) added a cancel message from PTT_R to the PTT_GCx state machines that is sent when an Error Response TTIU is received; d) added the sending of a cancel message from PTT_R to the PTT_SCx state machines if an unsupported or reserved value is received in the Training Control word; Bye for now, George Penokie LSI Corporation 3033 41st St. NW Suite 100 Rochester, MN 55901 507-328-9017 george.penokie at lsi.com -----Original Message----- From: localadmin at scsibbs.lsi.com [mailto:localadmin at scsibbs.lsi.com] On Behalf Of T10 Document Administrator Sent: Wednesday, June 01, 2011 5:00 PM To: Penokie, George Subject: Re: RE: T10 Document Number Assigned (T10/11-036r5) 2011/06/01 16:00:26 Your request to upload a file or files to the T10 site has been accepted. Your PDF file will be posted at: http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-036r5.pdf Normally, the posting/archiving process takes about 30 minutes. Please contact John Lohmeyer should you need further assistance. "Penokie, George" wrote: > From: "Penokie, George" > To: T10 Document Administrator > Date: Wed, 1 Jun 2011 15:53:16 -0600 > Subject: RE: T10 Document Number Assigned (T10/11-036r5) > Extracted-To: AutoPost > > > > Bye for now, > George Penokie > > LSI Corporation > 3033 41st St. NW > Suite 100 > Rochester, MN 55901 > > 507-328-9017 > george.penokie at lsi.com > > > -----Original Message----- > From: localadmin at scsibbs.lsi.com [mailto:localadmin at scsibbs.lsi.com] On Behalf Of T10 Document Administrator > Sent: Wednesday, June 01, 2011 4:52 PM > To: Penokie, George > Subject: T10 Document Number Assigned (T10/11-036r5) > > 2011/06/01 15:52:27 (AD v1.36) > > ## Your T10 document number request has been approved and > ## the following document number was assigned: > > Document Number: T10/11-036r5 > Upload Code: AC_00638gvAtO5its3 (Do not delete or change this line.) > Document_Date: 2011/06/01 > Document_Author: George Penokie > Document_Title: SPL-2: Transmitter Training > Meeting_Agenda: SAS_Prot - Serial Attached SCSI Protocol > Meeting_Agenda2: none > Document_Comments: > Other_Number: > > ## POSTING YOUR DOCUMENT USING A WEB BROWSER > ## ----------------------------------------- > ## > ## You may upload the file(s) for your document using > ## the form at: > ## > ## http://www.t10.org/fupload.htm > ## > ## > ## POSTING YOUR DOCUMENT BY REPLYING TO THIS EMAIL > ## ----------------------------------------------- > ## > ## Please reply to this email and attach your document > ## to the reply email. Please attach both the source > ## file and a PDF file made from your source file. > ## The source file may be ZIP'd, but the PDF file must > ## not be ZIP'd. > ## > ## Please generate your PDF files for posting to be > ## compatible with Acrobat 5.x (PDF 1.4). (This > ## parameter is set in Distiller, Settings, Job > ## Options, Compatibility.) > ## > ## If you do not attach a PDF file, your upload will be > ## forwarded to an administrator. This will delay your > ## posting until the administrator can make the PDF file > ## for you. > ## > ## While you are not required to provide the source file, > ## it is strongly recommended that you do so. The source > ## file will be archived in case the PDF file must be > ## re-created. > ## > ## It is critical that your reply email include the above > ## Upload Code. Without it, your posting cannot be > ## processed. The filenames you use for your attachment(s) > ## are not important as long as the extensions are correct. > ## > ## > ## POSTING NON-PDF DOCUMENTS > ## ------------------------- > ## > ## A PDF file is necessary for the T10 mailings. You may > ## also post one or more non-PDF files on the T10 web site > ## as long as the extensions are all unique. These files > ## are not included in the T10 mailings, but are made > ## available for downloading. > ## > ## To post additional files on the T10 web site, edit the > ## Post File line to add the file extension(s) that you > ## want posted. Then attach file(s) with matching > ## extensions to your email. > ## > ## Example: To post an Excel spreadsheet in addition to > ## a PDF file, edit the line to read: Post_File: PDF XLS > ## > Post_File: PDF > ## > ## Any files you attach that do not match an extension > ## listed on the Post File line will be assumed to be a > ## source file and will be archived but not posted. > ## > ## > ## CHANGING YOUR MIND > ## ------------------ > ## > ## If you wish to cancel this document number, reply to > ## this email without any attachments and edit the > ## following line to change the word no to yes: > ## > Cancel_Document_Number: no > ## > ## Once you post a document, you cannot cancel it. > ## > ## > ## EDITING DOCUMENT INFORMATION > ## ---------------------------- > ## > ## If one of the above fields Document Date, Document > ## Title, Document Author, Document Title, Meeting > ## Agenda, Comments, and Other Number is no longer > ## accurate, you may edit it as necessary. > ## > ## Be careful if you edit the Meeting Agenda field; > ## only the first word is used. It must be one of > ## the words available on the Add_to_agenda pull-down > ## from the web site. These words may change > ## periodically and as of June 2002 they were: ADI, > ## CAP, MMC, PIP, SAS_Prot, SAS_PHY, SBP, SPI, SRP, > ## SSC, SSM, and T10. > ## > ## > ## COPYRIGHT POLICY > ## ---------------- > ## > ## Do not submit documents containing a copyright > ## statement unless you add the following statement: > ## > ## Permission is granted to members of INCITS, its > ## technical committees and their associated task > ## groups to reproduce this document for the purposes > ## of INCITS standardization activities, provided > ## this notice is included. > ## > ## If you upload a copyrighted document, with or without > ## this statement, it will be assumed implicitly that you > ## and your organization have given the above permission. > ## > ## > ## APPROPRIATE CONTENT > ## ------------------- > ## > ## Do not upload inappropriate material. If you do, your > ## files will be removed and your posting privileges will > ## be revoked. > > Attachment Converted: "C:\ATTACH\11-036r5.pdf" * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From dgilbert at interlog.com Thu Jun 2 14:40:21 2011 From: dgilbert at interlog.com (Douglas Gilbert) Date: Thu, 2 Jun 2011 17:40:21 -0400 Subject: spl-2: shadowy zoning enabled Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Douglas Gilbert * In spl2r01.pdf in the section on the SMP DISCOVER function (9.4.3.10) is the following sentence (page 582, middle): "The SHADOW ZONING ENABLED bit contains the shadow value of the ZONING ENABLED bit (see 4.9.3.1)." That would imply that table 231 (DISCOVER response) should define that bit. It doesn't. The current and former technical editors of that document do not deny this is a flaw (and Rob suggests byte 104 bit 0). The current editor wants a proposal to fix it. I'm not aware whether someone without standing at t10 can make a proposal. That seems pretty pointless anyway. Couldn't it just be an agenda item for the next SAS protocol meeting to fix? BTW sas2r16.pdf and spl-r07.pdf contain the same oversight. Doug Gilbert * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From tru.nguyen at sisa.samsung.com Thu Jun 2 17:53:30 2011 From: tru.nguyen at sisa.samsung.com (Truong Nguyen - SISA) Date: Thu, 2 Jun 2011 17:53:30 -0700 Subject: Format Unit SI bit Message-ID: Formatted message: HTML-formatted message In SBC3r27, in the Format Unit initialization pattern descriptor subclause 5.3.2.3, there is a statement regarding the SI bit precedence: "An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field." What is this statement supposed to mean specifically? It seems as though the statement was added some time ago in SBCr6: ftp://ftp.t10.org/t10/t10r/1996/r9610141.htm "Clarified SI by adding the statement An SI bit set to one shall take precedence over any other FORMAT UNIT field." I could not find any proposals associated with the modification. Thanks, Truong Nguyen Samsung Information Systems America From keiji_katata at post.pioneer.co.jp Thu Jun 2 23:38:36 2011 From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp) Date: Fri, 3 Jun 2011 15:38:36 +0900 Subject: Posted: draft May meeting minutes Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * keiji_katata at post.pioneer.co.jp * Hello all, I posted April meeting minutes and draft May meeting minutes on ftp. ftp.avc-pioneer.com/Mtfuji_8/Minutes DraftMinMay11.pdf MinApr11.pdf And I also posted a comparison chart for ZPready state discussion in May meeting. ftp.avc-pioneer.com/Mtfuji_8/Proposal/Jun11/Comparison chart20110603.doc I think ATA Power management model discussion should be separated from ZPready state discussion. It may be an implementation matter. Because there is no standards that describe the relationship of them. Could you please check your implementation of the ATA Power management commands and let me know your opinion. Best regards, Keiji Katata PIONEER CORP. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Mark.Evans at wdc.com Fri Jun 3 08:56:05 2011 From: Mark.Evans at wdc.com (Mark Evans) Date: Fri, 3 Jun 2011 08:56:05 -0700 Subject: Format Unit SI bit Message-ID: Formatted message: HTML-formatted message Hi Truong, The SI bit was added into the INITIALIZATION PATTERN DESCRIPTOR for the FORMAT UNIT command in SBCr-05 based on proposal 96-186R1. As you wrote the definition of the bit was modified slightly in SBC-r06 as the result of discussion at the SCSI working group meetings in October of 1996. The definition of the SI bit has not been changed since that time. What I think we really intended the new wording to mean is, "If the SI bit its set to one, then the device server shall ignore: a) the FMTPINFO field; b) the FMTDATA bit; c) the CMPLST bit; d) the DEFECT LIST FORMAT field; e) all of the bits and fields in the parameter list header, except the IMMED bit; and f) any defect list data. Others may correct me if I'm wrong. You know who you are, and I'm sure you will - ha! Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Truong Nguyen - SISA Sent: Thursday, June 02, 2011 5:54 PM To: t10 at t10.org Subject: Format Unit SI bit In SBC3r27, in the Format Unit initialization pattern descriptor subclause 5.3.2.3, there is a statement regarding the SI bit precedence: "An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field." What is this statement supposed to mean specifically? It seems as though the statement was added some time ago in SBCr6: ftp://ftp.t10.org/t10/t10r/1996/r9610141.htm "Clarified SI by adding the statement An SI bit set to one shall take precedence over any other FORMAT UNIT field." I could not find any proposals associated with the modification. Thanks, Truong Nguyen Samsung Information Systems America From lohmeyer at t10.org Sat Jun 4 23:00:55 2011 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 5 Jun 2011 00:00:55 -0600 Subject: Recent T10 documents uploaded since 2011/05/29 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SPL-2: Transmitter Training (by: George Penokie) T10/11-036r5 Uploaded: 2011/06/01 1198762 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-036r5.pdf Foxconn - Combo PCIe-SAS 3 Connector SI Data (by: Fred Fons) T10/11-198r2 Uploaded: 2011/06/03 543154 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-198r2.pdf SOX - PQI and NVMe(r) Queuing Comparison (by: Ie-Wei Njoo) T10/11-228r1 Uploaded: 2011/06/01 427900 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-228r1.pdf SAS_PHY: SAS3 Specification using SAS3_EYEOPENING (by: Mathieu Gagnon) T10/11-234r1 Uploaded: 2011/06/02 279982 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-234r1.pdf Minutes SMC May 09, 2011 (by: Kevin Butt) T10/11-236r0 Uploaded: 2011/06/01 36089 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-236r0.pdf Minutes SSC4 WG May 10, 2011 (by: Kevin Butt) T10/11-237r0 Uploaded: 2011/06/01 53579 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-237r0.pdf Minutes of SAS PHY Working Group conference call May 26, 2011 (by: Alvin Cox) T10/11-262r0 Uploaded: 2011/06/02 23748 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-262r0.pdf Minutes ADC-3 letter ballot resolution conference call 1, June 2011 (by: Curtis Ballard) T10/11-263r0 Uploaded: 2011/06/03 27273 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-263r0.pdf SAS 2-port HDD connector crosstalk port assignments (by: Galen Fromm) T10/11-266r0 Uploaded: 2011/06/02 252886 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-266r0.pdf Working Drafts -------------- SCSI Block Commands - 3 (SBC-3) (Editor: Mark Evans) Rev: 27 Uploaded: 2011/06/01 1654863 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r27.pdf SAS Protocol Layer - 2 (SPL-2) (Editor: George Penokie) Rev: 01 Uploaded: 2011/05/31 8248301 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl2r01.pdf (Report generated on 2011/06/05 at 00:00:55) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From gerry.houlder at seagate.com Tue Jun 7 08:17:46 2011 From: gerry.houlder at seagate.com (Gerry Houlder) Date: Tue, 7 Jun 2011 10:17:46 -0500 Subject: Format Unit SI bit Message-ID: Formatted message: HTML-formatted message I think Mark's interpretation is too broad. The SI bit is intended to trigger a vendor specific security initialize feature. Things the device has to do to implement this take precedence over other bits that might specify conflicting demands. However things that specify the required final format (e.g., logical block size, FMTPINFO) and whether existing defect lists are included or not (e.g., FMTDATA, CMPLST, DEFECT LIST FORMAT, defect list length) should still be obeyed. If an initialization pattern is specified, that should be the pattern left on the media after the security initialize is complete. The SI bit probably affects how defective areas (i.e., areas excluded from the user data area) are treated, but should not cause the device to ignore instructions about which areas are to be handled as defective areas. On Fri, Jun 3, 2011 at 10:56 AM, Mark Evans wrote: > Hi Truong, > > > > The SI bit was added into the INITIALIZATION PATTERN DESCRIPTOR for the > FORMAT UNIT command in SBCr-05 based on proposal 96-186R1. As you wrote the > definition of the bit was modified slightly in SBC-r06 as the result of > discussion at the SCSI working group meetings in October of 1996. The > definition of the SI bit has not been changed since that time. > > > > What I think we really intended the new wording to mean is, ?If the SI bit > its set to one, then the device server shall ignore: > > > > a) the FMTPINFO field; > > b) the FMTDATA bit; > > c) the CMPLST bit; > > d) the DEFECT LIST FORMAT field; > > e) all of the bits and fields in the parameter list header, except > the IMMED bit; and > > f) any defect list data. > > > > Others may correct me if I?m wrong. You know who you are, and I?m sure you > will ? ha! > > > > Please feel free to call or send an email to me with any comments or > questions that you have about this stuff. > > > > Regards, > > > > Mark Evans > Western Digital Corporation > 5863 Rue Ferrari > San Jose, CA 95138 > Email: mark.evans at wdc.com > > ------------------------------ > > *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Truong > Nguyen - SISA > *Sent:* Thursday, June 02, 2011 5:54 PM > *To:* t10 at t10.org > *Subject:* Format Unit SI bit > > > > In SBC3r27, in the Format Unit initialization pattern descriptor subclause > 5.3.2.3, there is a statement regarding the SI bit precedence: > > > > "An SI bit set to one shall take precedence over any other FORMAT UNIT CDB > field." > > > > What is this statement supposed to mean specifically? > > > > It seems as though the statement was added some time ago in SBCr6: > > > > ftp://ftp.t10.org/t10/t10r/1996/r9610141.htm > > > > "Clarified SI by adding the statement An SI bit set to one shall take > precedence over any other FORMAT UNIT field." > > > > I could not find any proposals associated with the modification. > > > > > > Thanks, > > > > Truong Nguyen > > > > Samsung Information Systems America > From George.Penokie at lsi.com Tue Jun 7 09:01:56 2011 From: George.Penokie at lsi.com (Penokie, George) Date: Tue, 7 Jun 2011 10:01:56 -0600 Subject: Format Unit SI bit Message-ID: Formatted message: HTML-formatted message You are both right and wrong. What happen when the SI bit is set depends on the customers specification. Is some cases the intent may that the device be totally inoperable (think the helicopter and all electronics need to be destroyed). In less radical conditions the drive may come back usable with data scrubbed off. At the time this was put in there was no agreement by the committee as to how scrubbed the data had to be, again that was intended to be left up to the customers specification. Bye for now, George Penokie LSI Corporation 3033 41st St. NW Suite 100 Rochester, MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder Sent: Tuesday, June 07, 2011 10:18 AM To: T10 Reflector Cc: Truong Nguyen - SISA Subject: Re: Format Unit SI bit I think Mark's interpretation is too broad. The SI bit is intended to trigger a vendor specific security initialize feature. Things the device has to do to implement this take precedence over other bits that might specify conflicting demands. However things that specify the required final format (e.g., logical block size, FMTPINFO) and whether existing defect lists are included or not (e.g., FMTDATA, CMPLST, DEFECT LIST FORMAT, defect list length) should still be obeyed. If an initialization pattern is specified, that should be the pattern left on the media after the security initialize is complete. The SI bit probably affects how defective areas (i.e., areas excluded from the user data area) are treated, but should not cause the device to ignore instructions about which areas are to be handled as defective areas. On Fri, Jun 3, 2011 at 10:56 AM, Mark Evans wrote: Hi Truong, The SI bit was added into the INITIALIZATION PATTERN DESCRIPTOR for the FORMAT UNIT command in SBCr-05 based on proposal 96-186R1. As you wrote the definition of the bit was modified slightly in SBC-r06 as the result of discussion at the SCSI working group meetings in October of 1996. The definition of the SI bit has not been changed since that time. What I think we really intended the new wording to mean is, "If the SI bit its set to one, then the device server shall ignore: a) the FMTPINFO field; b) the FMTDATA bit; c) the CMPLST bit; d) the DEFECT LIST FORMAT field; e) all of the bits and fields in the parameter list header, except the IMMED bit; and f) any defect list data. Others may correct me if I'm wrong. You know who you are, and I'm sure you will - ha! Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Truong Nguyen - SISA Sent: Thursday, June 02, 2011 5:54 PM To: t10 at t10.org Subject: Format Unit SI bit In SBC3r27, in the Format Unit initialization pattern descriptor subclause 5.3.2.3, there is a statement regarding the SI bit precedence: "An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field." What is this statement supposed to mean specifically? It seems as though the statement was added some time ago in SBCr6: ftp://ftp.t10.org/t10/t10r/1996/r9610141.htm "Clarified SI by adding the statement An SI bit set to one shall take precedence over any other FORMAT UNIT field." I could not find any proposals associated with the modification. Thanks, Truong Nguyen Samsung Information Systems America From Mark.Evans at wdc.com Tue Jun 7 10:39:25 2011 From: Mark.Evans at wdc.com (Mark Evans) Date: Tue, 7 Jun 2011 10:39:25 -0700 Subject: Format Unit SI bit Message-ID: Formatted message: HTML-formatted message Hi George, There are just too many "shalls" in the definition for the bit set to one for this to be as open-ended as you describe: a) ...the device server shall attempt to write the initialization pattern to all areas of the medium including those that may have been reassigned (i.e., are in a defect list)...; b) ...An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field...; and c) ...the initialization pattern shall be written using a security erasure write technique.... Though I'll admit that item (c) is certainly vendor specific, I don't see where there is even a hint that the target device will end up being "totally inoperable". Gerry, I can see now that all of the information in the command and parameter data could be used if the logical unit was to perform the security initialize function and then finish with a normal format operation. We don't say this anyplace, but this condition could fall into George's list of vendor specific behavior. All of that written, I still think we need to clarify item (b). I now think that what was meant is: "...the security initialize function shall take precedence over any other function specified by the FORMAT UNIT command." To me this means that you have to do the security initialize stuff first, then whatever else you do is vendor specific. Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie, George Sent: Tuesday, June 07, 2011 9:02 AM To: Gerry Houlder; T10 Reflector Cc: Truong Nguyen - SISA Subject: RE: Format Unit SI bit You are both right and wrong. What happen when the SI bit is set depends on the customers specification. Is some cases the intent may that the device be totally inoperable (think the helicopter and all electronics need to be destroyed). In less radical conditions the drive may come back usable with data scrubbed off. At the time this was put in there was no agreement by the committee as to how scrubbed the data had to be, again that was intended to be left up to the customers specification. Bye for now, George Penokie LSI Corporation 3033 41st St. NW Suite 100 Rochester, MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder Sent: Tuesday, June 07, 2011 10:18 AM To: T10 Reflector Cc: Truong Nguyen - SISA Subject: Re: Format Unit SI bit I think Mark's interpretation is too broad. The SI bit is intended to trigger a vendor specific security initialize feature. Things the device has to do to implement this take precedence over other bits that might specify conflicting demands. However things that specify the required final format (e.g., logical block size, FMTPINFO) and whether existing defect lists are included or not (e.g., FMTDATA, CMPLST, DEFECT LIST FORMAT, defect list length) should still be obeyed. If an initialization pattern is specified, that should be the pattern left on the media after the security initialize is complete. The SI bit probably affects how defective areas (i.e., areas excluded from the user data area) are treated, but should not cause the device to ignore instructions about which areas are to be handled as defective areas. On Fri, Jun 3, 2011 at 10:56 AM, Mark Evans wrote: Hi Truong, The SI bit was added into the INITIALIZATION PATTERN DESCRIPTOR for the FORMAT UNIT command in SBCr-05 based on proposal 96-186R1. As you wrote the definition of the bit was modified slightly in SBC-r06 as the result of discussion at the SCSI working group meetings in October of 1996. The definition of the SI bit has not been changed since that time. What I think we really intended the new wording to mean is, "If the SI bit its set to one, then the device server shall ignore: a) the FMTPINFO field; b) the FMTDATA bit; c) the CMPLST bit; d) the DEFECT LIST FORMAT field; e) all of the bits and fields in the parameter list header, except the IMMED bit; and f) any defect list data. Others may correct me if I'm wrong. You know who you are, and I'm sure you will - ha! Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Truong Nguyen - SISA Sent: Thursday, June 02, 2011 5:54 PM To: t10 at t10.org Subject: Format Unit SI bit In SBC3r27, in the Format Unit initialization pattern descriptor subclause 5.3.2.3, there is a statement regarding the SI bit precedence: "An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field." What is this statement supposed to mean specifically? It seems as though the statement was added some time ago in SBCr6: ftp://ftp.t10.org/t10/t10r/1996/r9610141.htm "Clarified SI by adding the statement An SI bit set to one shall take precedence over any other FORMAT UNIT field." I could not find any proposals associated with the modification. Thanks, Truong Nguyen Samsung Information Systems America From jon.haswell at sisa.samsung.com Tue Jun 7 11:27:45 2011 From: jon.haswell at sisa.samsung.com (Jon Haswell - SISA) Date: Tue, 7 Jun 2011 11:27:45 -0700 Subject: Format Unit SI bit Message-ID: Formatted message: HTML-formatted message I would agree with your last comment, re needing to clarify (b). Wording such as 'take precedence over' is very ambiguous. To me 'taking precedence over' implies it overrides other settings if they conflict, but any conflict is vendor unique/unspecified so nobody can rely on what will or will not be overridden. We are currently implementing it so we do the security initialize first and then we implement everything else, we actually have no conflicts so we implement every other function/feature requested after the initialize is completed. I would prefer to see some statement that is definitive such as, 'When the SI bit is specified all other options are ignore' if that is really what is intended. Or if not let's get specific as we do in other commands/mode pages where we define what bits are honored/ignored where we have multiple bits that conflict/interact. Thanks Jon Haswell SSD Development Office 408 544 5869 Cell 408 472 2495 From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark Evans Sent: Tuesday, June 07, 2011 10:39 AM To: Penokie, George; Gerry Houlder; T10 Reflector Cc: Truong Nguyen - SISA Subject: RE: Format Unit SI bit Hi George, There are just too many "shalls" in the definition for the bit set to one for this to be as open-ended as you describe: a) ...the device server shall attempt to write the initialization pattern to all areas of the medium including those that may have been reassigned (i.e., are in a defect list)...; b) ...An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field...; and c) ...the initialization pattern shall be written using a security erasure write technique.... Though I'll admit that item (c) is certainly vendor specific, I don't see where there is even a hint that the target device will end up being "totally inoperable". Gerry, I can see now that all of the information in the command and parameter data could be used if the logical unit was to perform the security initialize function and then finish with a normal format operation. We don't say this anyplace, but this condition could fall into George's list of vendor specific behavior. All of that written, I still think we need to clarify item (b). I now think that what was meant is: "...the security initialize function shall take precedence over any other function specified by the FORMAT UNIT command." To me this means that you have to do the security initialize stuff first, then whatever else you do is vendor specific. Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie, George Sent: Tuesday, June 07, 2011 9:02 AM To: Gerry Houlder; T10 Reflector Cc: Truong Nguyen - SISA Subject: RE: Format Unit SI bit You are both right and wrong. What happen when the SI bit is set depends on the customers specification. Is some cases the intent may that the device be totally inoperable (think the helicopter and all electronics need to be destroyed). In less radical conditions the drive may come back usable with data scrubbed off. At the time this was put in there was no agreement by the committee as to how scrubbed the data had to be, again that was intended to be left up to the customers specification. Bye for now, George Penokie LSI Corporation 3033 41st St. NW Suite 100 Rochester, MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder Sent: Tuesday, June 07, 2011 10:18 AM To: T10 Reflector Cc: Truong Nguyen - SISA Subject: Re: Format Unit SI bit I think Mark's interpretation is too broad. The SI bit is intended to trigger a vendor specific security initialize feature. Things the device has to do to implement this take precedence over other bits that might specify conflicting demands. However things that specify the required final format (e.g., logical block size, FMTPINFO) and whether existing defect lists are included or not (e.g., FMTDATA, CMPLST, DEFECT LIST FORMAT, defect list length) should still be obeyed. If an initialization pattern is specified, that should be the pattern left on the media after the security initialize is complete. The SI bit probably affects how defective areas (i.e., areas excluded from the user data area) are treated, but should not cause the device to ignore instructions about which areas are to be handled as defective areas. On Fri, Jun 3, 2011 at 10:56 AM, Mark Evans wrote: Hi Truong, The SI bit was added into the INITIALIZATION PATTERN DESCRIPTOR for the FORMAT UNIT command in SBCr-05 based on proposal 96-186R1. As you wrote the definition of the bit was modified slightly in SBC-r06 as the result of discussion at the SCSI working group meetings in October of 1996. The definition of the SI bit has not been changed since that time. What I think we really intended the new wording to mean is, "If the SI bit its set to one, then the device server shall ignore: a) the FMTPINFO field; b) the FMTDATA bit; c) the CMPLST bit; d) the DEFECT LIST FORMAT field; e) all of the bits and fields in the parameter list header, except the IMMED bit; and f) any defect list data. Others may correct me if I'm wrong. You know who you are, and I'm sure you will - ha! Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Truong Nguyen - SISA Sent: Thursday, June 02, 2011 5:54 PM To: t10 at t10.org Subject: Format Unit SI bit In SBC3r27, in the Format Unit initialization pattern descriptor subclause 5.3.2.3, there is a statement regarding the SI bit precedence: "An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field." What is this statement supposed to mean specifically? It seems as though the statement was added some time ago in SBCr6: ftp://ftp.t10.org/t10/t10r/1996/r9610141.htm "Clarified SI by adding the statement An SI bit set to one shall take precedence over any other FORMAT UNIT field." I could not find any proposals associated with the modification. Thanks, Truong Nguyen Samsung Information Systems America From Elliott at hp.com Tue Jun 7 11:58:06 2011 From: Elliott at hp.com (Elliott, Robert (Server Storage)) Date: Tue, 7 Jun 2011 18:58:06 +0000 Subject: Format Unit SI bit Message-ID: Formatted message: HTML-formatted message Now that the SANITIZE command has made it into the SBC-3 working draft (sbc3r27), the FORMAT UNIT command's SI bit should be marked obsolete or vendor-specific. --- Rob Elliott HP Server Storage From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Jon Haswell - SISA Sent: Tuesday, 07 June, 2011 1:28 PM To: Mark Evans; Penokie, George; Gerry Houlder; T10 Reflector Cc: Truong Nguyen - SISA Subject: RE: Format Unit SI bit I would agree with your last comment, re needing to clarify (b). Wording such as 'take precedence over' is very ambiguous. To me 'taking precedence over' implies it overrides other settings if they conflict, but any conflict is vendor unique/unspecified so nobody can rely on what will or will not be overridden. We are currently implementing it so we do the security initialize first and then we implement everything else, we actually have no conflicts so we implement every other function/feature requested after the initialize is completed. I would prefer to see some statement that is definitive such as, 'When the SI bit is specified all other options are ignore' if that is really what is intended. Or if not let's get specific as we do in other commands/mode pages where we define what bits are honored/ignored where we have multiple bits that conflict/interact. Thanks Jon Haswell SSD Development Office 408 544 5869 Cell 408 472 2495 From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark Evans Sent: Tuesday, June 07, 2011 10:39 AM To: Penokie, George; Gerry Houlder; T10 Reflector Cc: Truong Nguyen - SISA Subject: RE: Format Unit SI bit Hi George, There are just too many "shalls" in the definition for the bit set to one for this to be as open-ended as you describe: a) ...the device server shall attempt to write the initialization pattern to all areas of the medium including those that may have been reassigned (i.e., are in a defect list)...; b) ...An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field...; and c) ...the initialization pattern shall be written using a security erasure write technique.... Though I'll admit that item (c) is certainly vendor specific, I don't see where there is even a hint that the target device will end up being "totally inoperable". Gerry, I can see now that all of the information in the command and parameter data could be used if the logical unit was to perform the security initialize function and then finish with a normal format operation. We don't say this anyplace, but this condition could fall into George's list of vendor specific behavior. All of that written, I still think we need to clarify item (b). I now think that what was meant is: "...the security initialize function shall take precedence over any other function specified by the FORMAT UNIT command." To me this means that you have to do the security initialize stuff first, then whatever else you do is vendor specific. Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie, George Sent: Tuesday, June 07, 2011 9:02 AM To: Gerry Houlder; T10 Reflector Cc: Truong Nguyen - SISA Subject: RE: Format Unit SI bit You are both right and wrong. What happen when the SI bit is set depends on the customers specification. Is some cases the intent may that the device be totally inoperable (think the helicopter and all electronics need to be destroyed). In less radical conditions the drive may come back usable with data scrubbed off. At the time this was put in there was no agreement by the committee as to how scrubbed the data had to be, again that was intended to be left up to the customers specification. Bye for now, George Penokie LSI Corporation 3033 41st St. NW Suite 100 Rochester, MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder Sent: Tuesday, June 07, 2011 10:18 AM To: T10 Reflector Cc: Truong Nguyen - SISA Subject: Re: Format Unit SI bit I think Mark's interpretation is too broad. The SI bit is intended to trigger a vendor specific security initialize feature. Things the device has to do to implement this take precedence over other bits that might specify conflicting demands. However things that specify the required final format (e.g., logical block size, FMTPINFO) and whether existing defect lists are included or not (e.g., FMTDATA, CMPLST, DEFECT LIST FORMAT, defect list length) should still be obeyed. If an initialization pattern is specified, that should be the pattern left on the media after the security initialize is complete. The SI bit probably affects how defective areas (i.e., areas excluded from the user data area) are treated, but should not cause the device to ignore instructions about which areas are to be handled as defective areas. On Fri, Jun 3, 2011 at 10:56 AM, Mark Evans wrote: Hi Truong, The SI bit was added into the INITIALIZATION PATTERN DESCRIPTOR for the FORMAT UNIT command in SBCr-05 based on proposal 96-186R1. As you wrote the definition of the bit was modified slightly in SBC-r06 as the result of discussion at the SCSI working group meetings in October of 1996. The definition of the SI bit has not been changed since that time. What I think we really intended the new wording to mean is, "If the SI bit its set to one, then the device server shall ignore: a) the FMTPINFO field; b) the FMTDATA bit; c) the CMPLST bit; d) the DEFECT LIST FORMAT field; e) all of the bits and fields in the parameter list header, except the IMMED bit; and f) any defect list data. Others may correct me if I'm wrong. You know who you are, and I'm sure you will - ha! Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Truong Nguyen - SISA Sent: Thursday, June 02, 2011 5:54 PM To: t10 at t10.org Subject: Format Unit SI bit In SBC3r27, in the Format Unit initialization pattern descriptor subclause 5.3.2.3, there is a statement regarding the SI bit precedence: "An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field." What is this statement supposed to mean specifically? It seems as though the statement was added some time ago in SBCr6: ftp://ftp.t10.org/t10/t10r/1996/r9610141.htm "Clarified SI by adding the statement An SI bit set to one shall take precedence over any other FORMAT UNIT field." I could not find any proposals associated with the modification. Thanks, Truong Nguyen Samsung Information Systems America From gerry.houlder at seagate.com Tue Jun 7 12:06:08 2011 From: gerry.houlder at seagate.com (Gerry Houlder) Date: Tue, 7 Jun 2011 14:06:08 -0500 Subject: Format Unit SI bit Message-ID: Formatted message: HTML-formatted message If you want a more precise definition of your sanitize process, consider implementing the newly created SANITIZE command instead. This certainly eliminates most of the uncertainty you are concerned about. The command can be seen in SBC-3 rev. 27 or proposal 11-011 (latest revision). The hope is that the features described in this command will meet the needs of everyone planning to inplement a sanitize function instead of using the SI bit. On Tue, Jun 7, 2011 at 1:27 PM, Jon Haswell - SISA < jon.haswell at sisa.samsung.com> wrote: > I would agree with your last comment, re needing to clarify (b). Wording > such as ?take precedence over? is very ambiguous. To me ?taking precedence > over? implies it overrides other settings if they conflict, but any conflict > is vendor unique/unspecified so nobody can rely on what will or will not be > overridden. > > > > We are currently implementing it so we do the security initialize first and > then we implement everything else, we actually have no conflicts so we > implement every other function/feature requested after the initialize is > completed. > > > > I would prefer to see some statement that is definitive such as, ?When the > SI bit is specified all other options are ignore? if that is really what is > intended. Or if not let?s get specific as we do in other commands/mode pages > where we define what bits are honored/ignored where we have multiple bits > that conflict/interact. > > > > Thanks > > > > Jon Haswell > > SSD Development > > Office 408 544 5869 > > Cell 408 472 2495 > > > > *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Mark > Evans > *Sent:* Tuesday, June 07, 2011 10:39 AM > *To:* Penokie, George; Gerry Houlder; T10 Reflector > > *Cc:* Truong Nguyen - SISA > *Subject:* RE: Format Unit SI bit > > > > Hi George, > > > > There are just too many ?shalls? in the definition for the bit set to one > for this to be as open-ended as you describe: > > > > a) ?the device server shall attempt to write the initialization > pattern to all areas of the medium including those that may have been > reassigned (i.e., are in a defect list)?; > > b) ?An SI bit set to one shall take precedence over any other FORMAT > UNIT CDB field?; and > > c) ?the initialization pattern shall be written using a security > erasure write technique?. > > > > Though I?ll admit that item (c) is certainly vendor specific, I don?t see > where there is even a hint that the target device will end up being ?totally > inoperable?. > > > > Gerry, I can see now that all of the information in the command and > parameter data could be used if the logical unit was to perform the security > initialize function and then finish with a normal format operation. We > don?t say this anyplace, but this condition could fall into George?s list of > vendor specific behavior. > > > > All of that written, I still think we need to clarify item (b). I now > think that what was meant is: ??the security initialize function shall take > precedence over any other function specified by the FORMAT UNIT command.? > To me this means that you have to do the security initialize stuff first, > then whatever else you do is vendor specific. > > > > Please feel free to call or send an email to me with any comments or > questions that you have about this stuff. > > > > Regards, > > > > Mark Evans > Western Digital Corporation > 5863 Rue Ferrari > San Jose, CA 95138 > Email: mark.evans at wdc.com > ------------------------------ > > *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Penokie, > George > *Sent:* Tuesday, June 07, 2011 9:02 AM > *To:* Gerry Houlder; T10 Reflector > *Cc:* Truong Nguyen - SISA > *Subject:* RE: Format Unit SI bit > > > > You are both right and wrong. > > > > What happen when the SI bit is set depends on the customers specification. > Is some cases the intent may that the device be totally inoperable (think > the helicopter and all electronics need to be destroyed). In less radical > conditions the drive may come back usable with data scrubbed off. > > > > At the time this was put in there was no agreement by the committee as to > how scrubbed the data had to be, again that was intended to be left up to > the customers specification. > > > > Bye for now, > George Penokie > > LSI Corporation > 3033 41st St. NW > Suite 100 > Rochester, MN 55901 > > 507-328-9017 > george.penokie at lsi.com > > *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Gerry > Houlder > *Sent:* Tuesday, June 07, 2011 10:18 AM > *To:* T10 Reflector > *Cc:* Truong Nguyen - SISA > *Subject:* Re: Format Unit SI bit > > > > I think Mark's interpretation is too broad. The SI bit is intended to > trigger a vendor specific security initialize feature. Things the device has > to do to implement this take precedence over other bits that might specify > conflicting demands. However things that specify the required final format > (e.g., logical block size, FMTPINFO) and whether existing defect lists are > included or not (e.g., FMTDATA, CMPLST, DEFECT LIST FORMAT, defect list > length) should still be obeyed. If an initialization pattern is specified, > that should be the pattern left on the media after the security initialize > is complete. The SI bit probably affects how defective areas (i.e., areas > excluded from the user data area) are treated, but should not cause the > device to ignore instructions about which areas are to be handled as > defective areas. > > On Fri, Jun 3, 2011 at 10:56 AM, Mark Evans wrote: > > Hi Truong, > > > > The SI bit was added into the INITIALIZATION PATTERN DESCRIPTOR for the > FORMAT UNIT command in SBCr-05 based on proposal 96-186R1. As you wrote the > definition of the bit was modified slightly in SBC-r06 as the result of > discussion at the SCSI working group meetings in October of 1996. The > definition of the SI bit has not been changed since that time. > > > > What I think we really intended the new wording to mean is, ?If the SI bit > its set to one, then the device server shall ignore: > > > > a) the FMTPINFO field; > > b) the FMTDATA bit; > > c) the CMPLST bit; > > d) the DEFECT LIST FORMAT field; > > e) all of the bits and fields in the parameter list header, except > the IMMED bit; and > > f) any defect list data. > > > > Others may correct me if I?m wrong. You know who you are, and I?m sure you > will ? ha! > > > > Please feel free to call or send an email to me with any comments or > questions that you have about this stuff. > > > > Regards, > > > > Mark Evans > Western Digital Corporation > 5863 Rue Ferrari > San Jose, CA 95138 > Email: mark.evans at wdc.com > ------------------------------ > > *From:* owner-t10 at t10.org [mailto:owner-t10 at t10.org] *On Behalf Of *Truong > Nguyen - SISA > *Sent:* Thursday, June 02, 2011 5:54 PM > *To:* t10 at t10.org > *Subject:* Format Unit SI bit > > > > In SBC3r27, in the Format Unit initialization pattern descriptor subclause > 5.3.2.3, there is a statement regarding the SI bit precedence: > > > > "An SI bit set to one shall take precedence over any other FORMAT UNIT CDB > field." > > > > What is this statement supposed to mean specifically? > > > > It seems as though the statement was added some time ago in SBCr6: > > > > ftp://ftp.t10.org/t10/t10r/1996/r9610141.htm > > > > "Clarified SI by adding the statement An SI bit set to one shall take > precedence over any other FORMAT UNIT field." > > > > I could not find any proposals associated with the modification. > > > > > > Thanks, > > > > Truong Nguyen > > > > Samsung Information Systems America > > > From jon.haswell at sisa.samsung.com Tue Jun 7 12:40:55 2011 From: jon.haswell at sisa.samsung.com (Jon Haswell - SISA) Date: Tue, 7 Jun 2011 12:40:55 -0700 Subject: Format Unit SI bit Message-ID: Formatted message: HTML-formatted message I agree - we just wanted to try and implement this legacy function in an appropriate manner. Looking forward to hopeful a day in the future when the SI bit can be obsolete in favor of the sanitize command ... Jon Haswell SSD Development Office 408 544 5869 Cell 408 472 2495 From: Gerry Houlder [mailto:gerry.houlder at seagate.com] Sent: Tuesday, June 07, 2011 12:06 PM To: Jon Haswell - SISA Cc: T10 Reflector; Truong Nguyen - SISA Subject: Re: Format Unit SI bit If you want a more precise definition of your sanitize process, consider implementing the newly created SANITIZE command instead. This certainly eliminates most of the uncertainty you are concerned about. The command can be seen in SBC-3 rev. 27 or proposal 11-011 (latest revision). The hope is that the features described in this command will meet the needs of everyone planning to inplement a sanitize function instead of using the SI bit. On Tue, Jun 7, 2011 at 1:27 PM, Jon Haswell - SISA wrote: I would agree with your last comment, re needing to clarify (b). Wording such as 'take precedence over' is very ambiguous. To me 'taking precedence over' implies it overrides other settings if they conflict, but any conflict is vendor unique/unspecified so nobody can rely on what will or will not be overridden. We are currently implementing it so we do the security initialize first and then we implement everything else, we actually have no conflicts so we implement every other function/feature requested after the initialize is completed. I would prefer to see some statement that is definitive such as, 'When the SI bit is specified all other options are ignore' if that is really what is intended. Or if not let's get specific as we do in other commands/mode pages where we define what bits are honored/ignored where we have multiple bits that conflict/interact. Thanks Jon Haswell SSD Development Office 408 544 5869 Cell 408 472 2495 From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Mark Evans Sent: Tuesday, June 07, 2011 10:39 AM To: Penokie, George; Gerry Houlder; T10 Reflector Cc: Truong Nguyen - SISA Subject: RE: Format Unit SI bit Hi George, There are just too many "shalls" in the definition for the bit set to one for this to be as open-ended as you describe: a) ...the device server shall attempt to write the initialization pattern to all areas of the medium including those that may have been reassigned (i.e., are in a defect list)...; b) ...An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field...; and c) ...the initialization pattern shall be written using a security erasure write technique.... Though I'll admit that item (c) is certainly vendor specific, I don't see where there is even a hint that the target device will end up being "totally inoperable". Gerry, I can see now that all of the information in the command and parameter data could be used if the logical unit was to perform the security initialize function and then finish with a normal format operation. We don't say this anyplace, but this condition could fall into George's list of vendor specific behavior. All of that written, I still think we need to clarify item (b). I now think that what was meant is: "...the security initialize function shall take precedence over any other function specified by the FORMAT UNIT command." To me this means that you have to do the security initialize stuff first, then whatever else you do is vendor specific. Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Penokie, George Sent: Tuesday, June 07, 2011 9:02 AM To: Gerry Houlder; T10 Reflector Cc: Truong Nguyen - SISA Subject: RE: Format Unit SI bit You are both right and wrong. What happen when the SI bit is set depends on the customers specification. Is some cases the intent may that the device be totally inoperable (think the helicopter and all electronics need to be destroyed). In less radical conditions the drive may come back usable with data scrubbed off. At the time this was put in there was no agreement by the committee as to how scrubbed the data had to be, again that was intended to be left up to the customers specification. Bye for now, George Penokie LSI Corporation 3033 41st St. NW Suite 100 Rochester, MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Gerry Houlder Sent: Tuesday, June 07, 2011 10:18 AM To: T10 Reflector Cc: Truong Nguyen - SISA Subject: Re: Format Unit SI bit I think Mark's interpretation is too broad. The SI bit is intended to trigger a vendor specific security initialize feature. Things the device has to do to implement this take precedence over other bits that might specify conflicting demands. However things that specify the required final format (e.g., logical block size, FMTPINFO) and whether existing defect lists are included or not (e.g., FMTDATA, CMPLST, DEFECT LIST FORMAT, defect list length) should still be obeyed. If an initialization pattern is specified, that should be the pattern left on the media after the security initialize is complete. The SI bit probably affects how defective areas (i.e., areas excluded from the user data area) are treated, but should not cause the device to ignore instructions about which areas are to be handled as defective areas. On Fri, Jun 3, 2011 at 10:56 AM, Mark Evans wrote: Hi Truong, The SI bit was added into the INITIALIZATION PATTERN DESCRIPTOR for the FORMAT UNIT command in SBCr-05 based on proposal 96-186R1. As you wrote the definition of the bit was modified slightly in SBC-r06 as the result of discussion at the SCSI working group meetings in October of 1996. The definition of the SI bit has not been changed since that time. What I think we really intended the new wording to mean is, "If the SI bit its set to one, then the device server shall ignore: a) the FMTPINFO field; b) the FMTDATA bit; c) the CMPLST bit; d) the DEFECT LIST FORMAT field; e) all of the bits and fields in the parameter list header, except the IMMED bit; and f) any defect list data. Others may correct me if I'm wrong. You know who you are, and I'm sure you will - ha! Please feel free to call or send an email to me with any comments or questions that you have about this stuff. Regards, Mark Evans Western Digital Corporation 5863 Rue Ferrari San Jose, CA 95138 Email: mark.evans at wdc.com ________________________________ From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Truong Nguyen - SISA Sent: Thursday, June 02, 2011 5:54 PM To: t10 at t10.org Subject: Format Unit SI bit In SBC3r27, in the Format Unit initialization pattern descriptor subclause 5.3.2.3, there is a statement regarding the SI bit precedence: "An SI bit set to one shall take precedence over any other FORMAT UNIT CDB field." What is this statement supposed to mean specifically? It seems as though the statement was added some time ago in SBCr6: ftp://ftp.t10.org/t10/t10r/1996/r9610141.htm "Clarified SI by adding the statement An SI bit set to one shall take precedence over any other FORMAT UNIT field." I could not find any proposals associated with the modification. Thanks, Truong Nguyen Samsung Information Systems America From alvin.cox at seagate.com Wed Jun 8 13:06:57 2011 From: alvin.cox at seagate.com (Alvin Cox) Date: Wed, 8 Jun 2011 15:06:57 -0500 Subject: Reminder: SAS PHY WG conference call, 10:00 am CDT, June 9, 2011 Message-ID: Formatted message: HTML-formatted message Agenda: AC coupling capacitor requirements [Felton] SSC requirements: How much SSC is needed? [Olawsky] Connector updates 11-270r0 * From the T10 Reflector (t10 at t10.org), posted by: * John Lohmeyer * Procrastinators: You have 3 more days to make your hotel reservation for the July T10 meetings in Colorado Springs. The meeting announcement, with a link to the Hilton reservations site, is available at: http://www.t10.org/ftp/t10/announce/ann-m104.pdf Remember to say your reservation is for one person even if your spouse is staying with you (or you'll be quoted a higher rate). If you have any problems making your reservation, please let me know and I will be glad to help. After the cutoff date, I will try to help, but whatever rooms remain in the guest block go back into the general hotel room pool. The Hilton reservations site will say there is a parking fee, but self-parking is included in the group rate. LSI will be hosting a reception at the Phantom Canyon micro-brewery (and pool hall) on Wednesday evening. You can bring your spouse, but they do not allow minors. We will be having BBQ again this year. I hope to see you next month! John -- John Lohmeyer Email: lohmeyer at t10.org LSI Corp. Voice: +1-719-533-7560 4420 ArrowsWest Dr. Cell: +1-719-338-1642 Colo Spgs, CO 80907 * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From lohmeyer at t10.org Sat Jun 11 23:01:00 2011 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 12 Jun 2011 00:01:00 -0600 Subject: Recent T10 documents uploaded since 2011/06/05 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- (SOP) - (PQI) PCIe Queuing Interface (by: Ie-Wei Njoo, Tim Symons, Neil Wanamaker) T10/11-157r7 Uploaded: 2011/06/06 1829006 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-157r7.pdf SOX - PQI and NVMe(r) Queuing Comparison (by: Ie-Wei Njoo) T10/11-228r2 Uploaded: 2011/06/08 622824 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-228r2.pdf SPC-4: Inconsistent Mode Page/Subpage Code Definitions (by: Ralph Weber) T10/11-247r1 Uploaded: 2011/06/08 46021 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-247r1.pdf Minutes of SAS PHY Working Group - May 10, 2011 (by: Alvin Cox) T10/11-251r1 Uploaded: 2011/06/06 36269 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-251r1.pdf Minutes of SCSI over PCIe (SOP) teleconference 2011-05-23 (by: Rob Elliott) T10/11-260r0 Uploaded: 2011/06/06 84985 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-260r0.pdf Minutes of SAS PHY Working Group conference call May 26, 2011 (by: Alvin Cox) T10/11-262r1 Uploaded: 2011/06/06 24456 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-262r1.pdf Minutes of SAS PHY Working Group conference call June 2, 2011 (by: Alvin Cox) T10/11-265r0 Uploaded: 2011/06/05 26216 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-265r0.pdf Cap testing and requirements (by: Mickey Felton) T10/11-267r0 Uploaded: 2011/06/09 288917 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-267r0.pdf NEXT vs. FEXT Measurement Configurations (by: Doron Lapidot) T10/11-268r0 Uploaded: 2011/06/07 84722 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-268r0.pdf SAS-3 12G Connector Drive Power Pin Configuration (by: Ray Pavlak) T10/11-270r0 Uploaded: 2011/06/08 154369 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-270r0.pdf Working Drafts -------------- (Report generated on 2011/06/12 at 00:01:00) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From curtis.stevens at wdc.com Sun Jun 12 15:44:31 2011 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Sun, 12 Jun 2011 15:44:31 -0700 Subject: SOP Proposals Message-ID: Formatted message: HTML-formatted message I have uploaded 4 SOP proposals for discussion at the conference call on Monday. 11-276 - The initial draft of SOP. This is mainly template material with some information filled in. I would like to vote this at the July plenary as the rev 0 11-277 - SOP Architecture. This is the proposed subclause 4.1 11-278 - SOP Domains. This is the proposed subclause 4.2 11-279 - SOP IU Definitions. This is the proposed list of IU definitions targeted at subclause 5.1. I also considered pulling out some of the other material and starting proposals, but chose to simply leave in the empty subclauses. ------------------------------------------------- Curtis E. Stevens Director, Standards & Features Technology 3355 Michelson Dr. #100 Office: 1-1041 Irvine, Ca. 92612 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: Curtis.Stevens at WDC.com Remember, you may only be blamed for something if you are actually doing something. From keiji_katata at post.pioneer.co.jp Mon Jun 13 02:32:32 2011 From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp) Date: Mon, 13 Jun 2011 18:32:32 +0900 Subject: Posted: draft June agenda and others Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * keiji_katata at post.pioneer.co.jp * Hello all, I posted draft June agenda, a missing file and revised spec. as follows; ftp.avc-pioneer.com/Mtfuji_8/Proposal/Jun11 DraftAgenda June11.doc GET_EVENT_STATUS_NOTIFICATION.pdf ftp.avc-pioneer.com/Mtfuji_8/Spec/FUJI8R0891.zip Commented items and many typos of 'filed' for 'field' were corrected. About ZPready state proposal, could you give your opinion? Especially your comment for - ZPready state - Timer in drive - Assumed problems BIOS impact, OS impact, Application software - ATA Power management model I want to know about "Event Driven of host Power Management" and "what is SATA Asynchronous Notification of host and why it is necessary for host". Current ZPODD model uses a timer in host. Is it "Event Driven of host Power Management"? Best regards, Keiji Katata PIONEER CORP. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From curtis.stevens at wdc.com Mon Jun 13 09:24:03 2011 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Mon, 13 Jun 2011 09:24:03 -0700 Subject: No SOP Telecon Today Message-ID: Formatted message: HTML-formatted message I may have inadvertently called a meeting for today. The SOP proposals are on the agenda for the F2F 16-17 June. ------------------------------------------------- Curtis E. Stevens Director, Standards & Features Technology 3355 Michelson Dr. #100 Office: 1-1041 Irvine, Ca. 92612 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: Curtis.Stevens at WDC.com Remember, you may only be blamed for something if you are actually doing something. From lohmeyer at t10.org Mon Jun 13 09:51:39 2011 From: lohmeyer at t10.org (John Lohmeyer) Date: Mon, 13 Jun 2011 10:51:39 -0600 Subject: Cut-off date extended for July T10 meeting Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * John Lohmeyer * The Antlers Hotel has added 5 rooms and extended the cutoff date for the July T10 meetings. If you haven't made your reservations yet, you should be able to do so until Friday. The reservations URL is in the meeting announcement at: http://www.t10.org/ftp/t10/announce/ann-m104.pdf -- John Lohmeyer Email: lohmeyer at t10.org LSI Corp. Voice: +1-719-533-7560 4420 ArrowsWest Dr. Cell: +1-719-338-1642 Colo Spgs, CO 80907 * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From John.Lohmeyer at lsi.com Mon Jun 13 09:53:35 2011 From: John.Lohmeyer at lsi.com (Lohmeyer, John) Date: Mon, 13 Jun 2011 10:53:35 -0600 Subject: Canceled: SOP Conference Call Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-3044-4.txt When: Monday, June 13, 2011 1:30 PM-3:30 PM (GMT-07:00) Mountain Time (US & Canada). Where: WebEx Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* CURTIS STEVENS invites you to an online meeting using WebEx. Meeting Number: 745 619 086 Meeting Password: This meeting does not require a password. To join this meeting (Now from iPhones too!) 1. Go to https://premconf.webex.com/premconf/j.php?J=745619086 2. Enter the meeting password: This meeting does not require a password. 3. Click ???Join Now???. 4. Follow the instructions that appear on your screen. Teleconference information Call-in toll-free number (Premiere): 1-866-546-3377 (US) Call-in number (Premiere): 1-719-234-7872 (US) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=9827629443&num=1866-546 -3377 Attendee access code: 982 762 9443 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, do not join the session. From roweber at IEEE.org Mon Jun 13 17:15:41 2011 From: roweber at IEEE.org (Ralph Weber) Date: Mon, 13 Jun 2011 19:15:41 -0500 Subject: SPC-4 r31 is available Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Ralph Weber * SPC-4 r31 has been uploaded to: http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r31.pdf In addition to the T10-approved substantive changes, several editorial changes associated with the Second Edition of the T10 Style Guide also have been made. The most conspicuous of these is the application of the new data structure formats (e.g., the multi-byte field changes). Several new sections |from the Style Guide conventions were also copied to this SPC-4 revision. This should provide plenty of opportunities to shower the editor with editorial corrections for goofs in the new formats. All the best, .Ralph * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From George.Penokie at lsi.com Tue Jun 14 07:38:48 2011 From: George.Penokie at lsi.com (Penokie, George) Date: Tue, 14 Jun 2011 08:38:48 -0600 Subject: T10 Document Number Assigned (T10/11-036r6) Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * "Penokie, George" * A new version of the transmitter training proposal has been posted. It is now complete as the coding description as been added. That will be the main discussion point in tomorrow's call. Revision 6 - Added the following: a) fixed the Control/Status TTIU table. The 3 coefficient requests should have been named Coefficient Request byte. There is no need to label the 3 coefficient statuses; b) changed the name of the encoding from Differential Manchester to Bi-phase Mark Code (BMC) which is a more accurate name for the code being used; c) added the BMC section to the proposal (see 5.3); d) allow the scrambler to be reinitialized at the end of Train_Tx-SNW; Bye for now, George Penokie LSI Corporation 3033 41st St. NW Suite 100 Rochester, MN 55901 507-328-9017 george.penokie at lsi.com -----Original Message----- From: localadmin at scsibbs.lsi.com [mailto:localadmin at scsibbs.lsi.com] On Behalf Of T10 Document Administrator Sent: Monday, June 13, 2011 5:40 PM To: Penokie, George Subject: Re: RE: T10 Document Number Assigned (T10/11-036r6) 2011/06/13 16:40:26 Your request to upload a file or files to the T10 site has been accepted. Your PDF file will be posted at: http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-036r6.pdf Normally, the posting/archiving process takes about 30 minutes. Please contact John Lohmeyer should you need further assistance. "Penokie, George" wrote: > From: "Penokie, George" > To: T10 Document Administrator > Date: Mon, 13 Jun 2011 16:30:57 -0600 > Subject: RE: T10 Document Number Assigned (T10/11-036r6) > Extracted-To: AutoPost > > > > Bye for now, > George Penokie > > LSI Corporation > 3033 41st St. NW > Suite 100 > Rochester, MN 55901 > > 507-328-9017 > george.penokie at lsi.com > > > -----Original Message----- > From: localadmin at scsibbs.lsi.com [mailto:localadmin at scsibbs.lsi.com] On Behalf Of T10 Document Administrator > Sent: Monday, June 13, 2011 5:25 PM > To: Penokie, George > Subject: T10 Document Number Assigned (T10/11-036r6) > > 2011/06/13 16:25:26 (AD v1.36) > > ## Your T10 document number request has been approved and > ## the following document number was assigned: > > Document Number: T10/11-036r6 > Upload Code: AC_00663cwfhe39twG (Do not delete or change this line.) > Document_Date: 2011/06/13 > Document_Author: George Penokie > Document_Title: SPL-2: Transmitter Training > Meeting_Agenda: SAS_Prot - Serial Attached SCSI Protocol > Meeting_Agenda2: none > Document_Comments: > Other_Number: > > ## POSTING YOUR DOCUMENT USING A WEB BROWSER > ## ----------------------------------------- > ## > ## You may upload the file(s) for your document using > ## the form at: > ## > ## http://www.t10.org/fupload.htm > ## > ## > ## POSTING YOUR DOCUMENT BY REPLYING TO THIS EMAIL > ## ----------------------------------------------- > ## > ## Please reply to this email and attach your document > ## to the reply email. Please attach both the source > ## file and a PDF file made from your source file. > ## The source file may be ZIP'd, but the PDF file must > ## not be ZIP'd. > ## > ## Please generate your PDF files for posting to be > ## compatible with Acrobat 5.x (PDF 1.4). (This > ## parameter is set in Distiller, Settings, Job > ## Options, Compatibility.) > ## > ## If you do not attach a PDF file, your upload will be > ## forwarded to an administrator. This will delay your > ## posting until the administrator can make the PDF file > ## for you. > ## > ## While you are not required to provide the source file, > ## it is strongly recommended that you do so. The source > ## file will be archived in case the PDF file must be > ## re-created. > ## > ## It is critical that your reply email include the above > ## Upload Code. Without it, your posting cannot be > ## processed. The filenames you use for your attachment(s) > ## are not important as long as the extensions are correct. > ## > ## > ## POSTING NON-PDF DOCUMENTS > ## ------------------------- > ## > ## A PDF file is necessary for the T10 mailings. You may > ## also post one or more non-PDF files on the T10 web site > ## as long as the extensions are all unique. These files > ## are not included in the T10 mailings, but are made > ## available for downloading. > ## > ## To post additional files on the T10 web site, edit the > ## Post File line to add the file extension(s) that you > ## want posted. Then attach file(s) with matching > ## extensions to your email. > ## > ## Example: To post an Excel spreadsheet in addition to > ## a PDF file, edit the line to read: Post_File: PDF XLS > ## > Post_File: PDF > ## > ## Any files you attach that do not match an extension > ## listed on the Post File line will be assumed to be a > ## source file and will be archived but not posted. > ## > ## > ## CHANGING YOUR MIND > ## ------------------ > ## > ## If you wish to cancel this document number, reply to > ## this email without any attachments and edit the > ## following line to change the word no to yes: > ## > Cancel_Document_Number: no > ## > ## Once you post a document, you cannot cancel it. > ## > ## > ## EDITING DOCUMENT INFORMATION > ## ---------------------------- > ## > ## If one of the above fields Document Date, Document > ## Title, Document Author, Document Title, Meeting > ## Agenda, Comments, and Other Number is no longer > ## accurate, you may edit it as necessary. > ## > ## Be careful if you edit the Meeting Agenda field; > ## only the first word is used. It must be one of > ## the words available on the Add_to_agenda pull-down > ## from the web site. These words may change > ## periodically and as of June 2002 they were: ADI, > ## CAP, MMC, PIP, SAS_Prot, SAS_PHY, SBP, SPI, SRP, > ## SSC, SSM, and T10. > ## > ## > ## COPYRIGHT POLICY > ## ---------------- > ## > ## Do not submit documents containing a copyright > ## statement unless you add the following statement: > ## > ## Permission is granted to members of INCITS, its > ## technical committees and their associated task > ## groups to reproduce this document for the purposes > ## of INCITS standardization activities, provided > ## this notice is included. > ## > ## If you upload a copyrighted document, with or without > ## this statement, it will be assumed implicitly that you > ## and your organization have given the above permission. > ## > ## > ## APPROPRIATE CONTENT > ## ------------------- > ## > ## Do not upload inappropriate material. If you do, your > ## files will be removed and your posting privileges will > ## be revoked. > > Attachment Converted: "C:\ATTACH\11-036r6.pdf" * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From alvin.cox at seagate.com Wed Jun 15 06:59:42 2011 From: alvin.cox at seagate.com (Alvin Cox) Date: Wed, 15 Jun 2011 08:59:42 -0500 Subject: Reminder: SAS PHY WG conference call, 10:00 am CDT, June 16, 2011 Message-ID: Formatted message: HTML-formatted message Agenda: SSC requirements: How much SSC is needed? [Olawsky] AC coupling for receiver only [Seidel] Connector updates Channel updates SAS-3 Electrical Spec (11-221r2 * From the T10 Reflector (t10 at t10.org), posted by: * "Penokie, George" * George Penokie has invited you to present at an online meeting using Microsoft(r) Office Live Meeting service. Join the meeting AUDIO INFORMATION Telephone Conferencing Choose one of the following: * Start the Office Live Meeting client, and then in the Voice & Video pane, click Join Conference. The conferencing service will call you at the number you specify. (Recommended) * Dial the conferencing service directly, and enter the participant code shown below: Toll-free: +1-8662147945 Toll: +1-7026964029 Participant Code: 5073289017 FIRST-TIME USERS To save time before the meeting, check your system to make sure it is ready to use Office Live Meeting. TROUBLESHOOTING Unable to join the meeting? Follow these steps: 1. Copy this address and paste into your web browser: https://www.livemeeting.com/cc/lsi/join 2. Copy and paste the required information: Meeting ID: 5KJCJS Entry Code: hc&wK6d Location: https://www.livemeeting.com/cc/lsi If you still cannot enter the meeting, contact support. NOTICE Office Live Meeting can be used to record meetings. By participating in this meeting, you agree that your communications may be monitored or recorded at any time during the meeting. Bye for now, George Penokie LSI Corporation 3033 41st St. NW Suite 100 Rochester, MN 55901 507-328-9017 george.penokie at lsi.com * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From kishore.k.karthikeyan at intel.com Wed Jun 15 10:32:13 2011 From: kishore.k.karthikeyan at intel.com (Karthikeyan, Kishore K) Date: Wed, 15 Jun 2011 10:32:13 -0700 Subject: Questions/comments regarding 11-036r6 proposal (Transmitter training) Message-ID: Formatted message: HTML-formatted message Attachment #1: image003.png Hi all I had some comments on the 11-036r6 proposal that I was hoping to get covered in the call today but the email I sent last night bounced from t10 reflector and unfortunately, I missed today's conference call too. Given below are the review comments/questions from my review of pages 1- 88 of 11-036r6. Thanks Kishore #1: Pg 33, last line "If the phy's receiver does not detect a pattern marker after a Train_Tx pattern then the pattern marker shall be invalid. What is the above statement trying to say? As there is no time bound for this pattern detection, what scenario is this statement trying to cover? #2: Pg 35 The control/status TTIU is used by a phy to: a) .... b) ...... Statement b) does not match the contents of the fields. Training status word contents are not used to receive status of the attached phy's transmitter. It is used to convey the current status of the transmitter training to the attached phy. #3: Pg 44 [cid:image003.png at 01CC2B45.51A8B350] Shouldn't this read as follows --> then a new Train_Tx-SNW shall be performed (if possible) or Train_Rx-SNW shall be performed (if Train_Tx-SNW not possible) based on the next highest, untried, commonly supported settings. #4: Pg 37 In the paragraph about phy reset problem A phy reset problem occurs: a) ---- b) ---- c) ---- Shouldn't we also add one more condition to this to cover Train_Tx-SNW? d) after a Train_Tx-SNW, if the Train_Tx-SNW is invalid and there are no additional, untried, commonly supported settings. See pg 81 --> 5.9.4.5.1 #5: Pg 54 Just below the figure Spelling mistake --> Transmitter #6: Page 53, last line Grammatical error --> after "of" #7: pg 55 Typo in figure --> TTIU instead of ITTU #8: Pg 81 Instead of "the phy shall", it should be "this state shall" in 2) #9: Pg 88 typo (use 1,2 and 3 instead of 1,1,1 in these paragraphs for the "transmitter Adjustment complete" and the "current coefficient") #10: Just for my understanding, what was the reason for disabling OOB detection during Train-Tx window? We don't disable it for Train-Rx then why disable it for Train-Tx? From George.Penokie at lsi.com Wed Jun 15 12:46:26 2011 From: George.Penokie at lsi.com (Penokie, George) Date: Wed, 15 Jun 2011 13:46:26 -0600 Subject: Questions/comments regarding 11-036r6 proposal (Transmitter training) Message-ID: Formatted message: HTML-formatted message Attachment #1: image001.png Kishore, Thanks for your comments. See my responses below. Bye for now, George Penokie LSI Corporation 3033 41st St. NW Suite 100 Rochester, MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Karthikeyan, Kishore K Sent: Wednesday, June 15, 2011 12:32 PM To: t10 at t10.org Subject: Questions/comments regarding 11-036r6 proposal (Transmitter training) Hi all I had some comments on the 11-036r6 proposal that I was hoping to get covered in the call today but the email I sent last night bounced from t10 reflector and unfortunately, I missed today's conference call too. Given below are the review comments/questions from my review of pages 1- 88 of 11-036r6. Thanks Kishore #1: Pg 33, last line "If the phy's receiver does not detect a pattern marker after a Train_Tx pattern then the pattern marker shall be invalid. What is the above statement trying to say? As there is no time bound for this pattern detection, what scenario is this statement trying to cover? GP - The Train-Tx pattern is very specific and clearly defined in table 9. If there is no patter marker immediately following the 58 dwords of zeros that is considered an invalid pattern marker. #2: Pg 35 The control/status TTIU is used by a phy to: a) .... b) ...... Statement b) does not match the contents of the fields. Training status word contents are not used to receive status of the attached phy's transmitter. It is used to convey the current status of the transmitter training to the attached phy. GP - It depends on what side of the but you are on. Your statement is correct but so is the one in the proposal. For now I am not making any change here. #3: Pg 44 [cid:image001.png at 01CC2B69.D2E95810] Shouldn't this read as follows --> then a new Train_Tx-SNW shall be performed (if possible) or Train_Rx-SNW shall be performed (if Train_Tx-SNW not possible) based on the next highest, untried, commonly supported settings. GP - Yes - Fixed #4: Pg 37 In the paragraph about phy reset problem A phy reset problem occurs: a) ---- b) ---- c) ---- Shouldn't we also add one more condition to this to cover Train_Tx-SNW? d) after a Train_Tx-SNW, if the Train_Tx-SNW is invalid and there are no additional, untried, commonly supported settings. See pg 81 --> 5.9.4.5.1 GP - Yes - Fixed #5: Pg 54 Just below the figure Spelling mistake --> Transmitter GP - Fixed #6: Page 53, last line Grammatical error --> after "of" GP - Fixed #7: pg 55 Typo in figure --> TTIU instead of ITTU GP - Fixed #8: Pg 81 Instead of "the phy shall", it should be "this state shall" in 2) GP - The 'the phy shall' wording is the way these things are stated in the SPxx state machines. Just look in SLP-2 and you see that statement all over the place in the SP state machine sections. #9: Pg 88 typo (use 1,2 and 3 instead of 1,1,1 in these paragraphs for the "transmitter Adjustment complete" and the "current coefficient") GP - Fixed #10: Just for my understanding, what was the reason for disabling OOB detection during Train-Tx window? We don't disable it for Train-Rx then why disable it for Train-Tx? GP - I am not an expert on this but what I understand is that Manchester encoded period is close to OOB timing and that could cause problems. From kishore.k.karthikeyan at intel.com Wed Jun 15 14:01:55 2011 From: kishore.k.karthikeyan at intel.com (Karthikeyan, Kishore K) Date: Wed, 15 Jun 2011 14:01:55 -0700 Subject: Questions/comments regarding 11-036r6 proposal (Transmitter training) Message-ID: Formatted message: HTML-formatted message Attachment #1: image001.png Hi George Thanks for the response. Regarding #1 Table 9 says that the pattern marker has to be present before the TTIU and not after the 58 scrambled dwords. My problem with this statement is that when will I generate this invalid pattern marker message? The valid/invalid pattern marker messages go to the PTT_PL state machine. So are we saying that the phy's receiver should generate an invalid pattern marker message even though no invalid pattern marker was detected (according to the definition of invalid pattern marker that we defined in 5.7.4.2.3.4.3). And how many messages will we generate and for how long? The statement makes it vague and open to different interpretations. Regarding #8: I made the comment about "the phy shall" because you seemed to have changed the wording from "the phy shall" to "this state shall" in the same section 5.9.4.4.1 --> see the first line of this section marked 1). I was trying to make it consistent because paragraph 1 of this state's description says "this state shall" and paragraph 2 says "the phy shall" Thanks Kishore From: Penokie, George [mailto:George.Penokie at lsi.com] Sent: Wednesday, June 15, 2011 12:46 PM To: Karthikeyan, Kishore K; t10 at t10.org Subject: RE: Questions/comments regarding 11-036r6 proposal (Transmitter training) Kishore, Thanks for your comments. See my responses below. Bye for now, George Penokie LSI Corporation 3033 41st St. NW Suite 100 Rochester, MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Karthikeyan, Kishore K Sent: Wednesday, June 15, 2011 12:32 PM To: t10 at t10.org Subject: Questions/comments regarding 11-036r6 proposal (Transmitter training) Hi all I had some comments on the 11-036r6 proposal that I was hoping to get covered in the call today but the email I sent last night bounced from t10 reflector and unfortunately, I missed today's conference call too. Given below are the review comments/questions from my review of pages 1- 88 of 11-036r6. Thanks Kishore #1: Pg 33, last line "If the phy's receiver does not detect a pattern marker after a Train_Tx pattern then the pattern marker shall be invalid. What is the above statement trying to say? As there is no time bound for this pattern detection, what scenario is this statement trying to cover? GP - The Train-Tx pattern is very specific and clearly defined in table 9. If there is no patter marker immediately following the 58 dwords of zeros that is considered an invalid pattern marker. #2: Pg 35 The control/status TTIU is used by a phy to: a) .... b) ...... Statement b) does not match the contents of the fields. Training status word contents are not used to receive status of the attached phy's transmitter. It is used to convey the current status of the transmitter training to the attached phy. GP - It depends on what side of the but you are on. Your statement is correct but so is the one in the proposal. For now I am not making any change here. #3: Pg 44 [cid:image001.png at 01CC2B5C.F3B4F4D0] Shouldn't this read as follows --> then a new Train_Tx-SNW shall be performed (if possible) or Train_Rx-SNW shall be performed (if Train_Tx-SNW not possible) based on the next highest, untried, commonly supported settings. GP - Yes - Fixed #4: Pg 37 In the paragraph about phy reset problem A phy reset problem occurs: a) ---- b) ---- c) ---- Shouldn't we also add one more condition to this to cover Train_Tx-SNW? d) after a Train_Tx-SNW, if the Train_Tx-SNW is invalid and there are no additional, untried, commonly supported settings. See pg 81 --> 5.9.4.5.1 GP - Yes - Fixed #5: Pg 54 Just below the figure Spelling mistake --> Transmitter GP - Fixed #6: Page 53, last line Grammatical error --> after "of" GP - Fixed #7: pg 55 Typo in figure --> TTIU instead of ITTU GP - Fixed #8: Pg 81 Instead of "the phy shall", it should be "this state shall" in 2) GP - The 'the phy shall' wording is the way these things are stated in the SPxx state machines. Just look in SLP-2 and you see that statement all over the place in the SP state machine sections. #9: Pg 88 typo (use 1,2 and 3 instead of 1,1,1 in these paragraphs for the "transmitter Adjustment complete" and the "current coefficient") GP - Fixed #10: Just for my understanding, what was the reason for disabling OOB detection during Train-Tx window? We don't disable it for Train-Rx then why disable it for Train-Tx? GP - I am not an expert on this but what I understand is that Manchester encoded period is close to OOB timing and that could cause problems. From keiji_katata at post.pioneer.co.jp Fri Jun 17 01:51:52 2011 From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp) Date: Fri, 17 Jun 2011 17:51:52 +0900 Subject: Posted: Lenovo comments Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * keiji_katata at post.pioneer.co.jp * Hello all, I posted comments from Lenovo on ftp. ftp.avc-pioneer.com/Mtfuji_8/Proposal/Jun11/Comparison chart20110617.pdf Best regards, Keiji Katata PIONEER CORP. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From keiji_katata at post.pioneer.co.jp Sat Jun 18 06:59:33 2011 From: keiji_katata at post.pioneer.co.jp (keiji_katata at post.pioneer.co.jp) Date: Sat, 18 Jun 2011 22:59:33 +0900 Subject: [MtFuji] Posted: Lenovo comments Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * keiji_katata at post.pioneer.co.jp * Hello all, I posted Pioneer comments on ftp. ftp.avc-pioneer.com/Mtfuji_8/Proposal/Jun11/Comparison chart20110618.pdf Best regards, Keiji Katata PIONEER CORP. keiji_katata at post.pioneer.co.jp@avc-pioneer.com on 2011/06/17 17:51:52 mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B $BAw?. $B7oL>(B: [MtFuji] Posted: Lenovo comments Hello all, I posted comments from Lenovo on ftp. ftp.avc-pioneer.com/Mtfuji_8/Proposal/Jun11/Comparison chart20110617.pdf Best regards, Keiji Katata PIONEER CORP. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From lohmeyer at t10.org Sat Jun 18 23:00:55 2011 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 19 Jun 2011 00:00:55 -0600 Subject: Recent T10 documents uploaded since 2011/06/12 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SPL-2: Transmitter Training (by: George Penokie) T10/11-036r6 Uploaded: 2011/06/13 1263561 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-036r6.pdf SPL-2: Transmitter Training (by: George Penokie) T10/11-036r7 Uploaded: 2011/06/15 1266163 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-036r7.pdf (SOP) - (PQI) PCIe Queuing Interface (by: Ie-Wei Njoo, Tim Symons, Neil Wanamaker) T10/11-157r8 Uploaded: 2011/06/15 1481652 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-157r8.pdf Minimizing host SGL copies in SOP+PQI (by: Rob Elliott) T10/11-209r2 Uploaded: 2011/06/15 116998 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-209r2.pdf SAS-3 Electrical Spec (by: Kevin Witt) T10/11-221r3 Uploaded: 2011/06/15 1515148 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-221r3.pdf NEXT vs. FEXT Measurement Configurations (by: Doron Lapidot) T10/11-268r1 Uploaded: 2011/06/13 204933 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-268r1.pdf Minutes of SCSI over PCIe (SOP) teleconference 2011-06-06 (by: Rob Elliott) T10/11-269r0 Uploaded: 2011/06/13 86225 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-269r0.pdf Minutes SMC-3 June 15, 2011 Phone conference (by: Kevin Butt) T10/11-271r0 Uploaded: 2011/06/15 33598 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-271r0.pdf Minutes of SAS PHY Working Group conference call June 9 2011 (by: Alvin Cox) T10/11-274r0 Uploaded: 2011/06/16 24403 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-274r0.pdf SAS-3 12Gbs Transmitter Deevice Test Proposal (by: Richard Mellitz) T10/11-275r0 Uploaded: 2011/06/15 1273450 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-275r0.pdf Proposed SOP Rev 0 (by: Curtis Stevens) T10/11-276r0 Uploaded: 2011/06/12 257863 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-276r0.pdf SOP Architecture (by: Curtis Stevens) T10/11-277r0 Uploaded: 2011/06/12 121921 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-277r0.pdf SOP Domains (by: Curtis Stevens) T10/11-278r0 Uploaded: 2011/06/12 170738 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-278r0.pdf SOP IU Definitions (by: Curtis Stevens) T10/11-279r0 Uploaded: 2011/06/12 199841 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-279r0.pdf SPL2: DISCOVER field SHADOW ZONE ENABLED bit missing (by: Brad Besmer) T10/11-280r0 Uploaded: 2011/06/14 62587 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-280r0.pdf SBC-3 Allow more commands in Sanitize Failed condition (by: Gerald Houlder) T10/11-281r0 Uploaded: 2011/06/15 31112 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-281r0.pdf SOP vs PQI IU header (by: Rob Elliott) T10/11-284r0 Uploaded: 2011/06/16 79651 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-284r0.pdf PQI object locations (by: Rob Elliott) T10/11-285r0 Uploaded: 2011/06/16 63026 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-285r0.pdf Working Drafts -------------- SCSI Primary Commands - 4 (SPC-4) (Editor: Ralph Weber) Rev: 31 Uploaded: 2011/06/13 5321770 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r31.pdf (Report generated on 2011/06/19 at 00:00:55) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From kdbutt at us.ibm.com Tue Jun 21 11:01:12 2011 From: kdbutt at us.ibm.com (Kevin D Butt) Date: Tue, 21 Jun 2011 11:01:12 -0700 Subject: 11-160r1: Return all log subpages Message-ID: Formatted message: HTML-formatted message I have posted an update to the proposal to clarify what is returned in all log subpages. My notes from last CAP meetings said I was supposed to reference the CDB in one of the paragraphs. I cannot resolve what was desired or how to do that. The posted proposal has an editors note above the paragraph in question. Any help would be appreciated. 2011/06/21 11:56:25 Your request to upload a file or files to the T10 site has been accepted. Your PDF file will be posted at: http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-160r1.pdf Thanks, Kevin D. Butt SCSI & Fibre Channel Architect, Tape Firmware Data Protection & Retention MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com From alvin.cox at seagate.com Wed Jun 22 09:57:58 2011 From: alvin.cox at seagate.com (Alvin Cox) Date: Wed, 22 Jun 2011 11:57:58 -0500 Subject: Reminder: No SAS PHY call on 6/23 Message-ID: Formatted message: HTML-formatted message No call this week. We will have a call on 6/30 at the normal time. -- Alvin Cox Seagate Technology, LLC Cell 405-206-4809 Office 405-392-3738 E-Mail alvin.cox at seagate.com From lohmeyer at t10.org Sat Jun 25 23:00:56 2011 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 26 Jun 2011 00:00:56 -0600 Subject: Recent T10 documents uploaded since 2011/06/19 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SPC: Returning all log subpages (by: Kevin Butt) T10/11-160r1 Uploaded: 2011/06/21 21048 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-160r1.pdf PQI Scatter Gather List and Descriptors (by: Steve Johnson) T10/11-166r4 Uploaded: 2011/06/23 93136 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-166r4.pdf ADC-3: Corrections to 11-094 (by: Kevin Butt) T10/11-188r1 Uploaded: 2011/06/20 44020 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-188r1.pdf SSC-4: PEWS setting resolution (by: Kevin Butt) T10/11-201r1 Uploaded: 2011/06/20 18641 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-201r1.pdf SSC-4: Clarify data lost in format operation (by: Kevin Butt) T10/11-218r1 Uploaded: 2011/06/20 27822 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-218r1.pdf SAS-3 Electrical Spec (by: Kevin Witt) T10/11-221r4 Uploaded: 2011/06/22 1517889 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-221r4.pdf SPL-2: Resolve Zone Group Persistency Issue (by: Brad Besmer) T10/11-264r0 Uploaded: 2011/06/20 103650 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-264r0.pdf SSC-4: Locate to EOD (by: Kevin Butt) T10/11-272r0 Uploaded: 2011/06/20 47910 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-272r0.pdf SSC-4: Remaining Capacity LP17 (by: Kevin Butt) T10/11-273r0 Uploaded: 2011/06/20 47766 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-273r0.pdf T11 Liaison Report June 2011 (by: Steven Wilson) T10/11-288r0 Uploaded: 2011/06/21 27420 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-288r0.pdf SAS-3 MultiLink connector and SFF-8639 ground compatibility (by: Alvin Cox) T10/11-289r0 Uploaded: 2011/06/21 890862 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=11-289r0.pdf Working Drafts -------------- SCSI Stream Commands - 4 (Editor: Dave Peterson) Rev: 01e Uploaded: 2011/06/22 4218399 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=ssc4r01e.pdf (Report generated on 2011/06/26 at 00:00:56) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From lohmeyer at t10.org Tue Jun 28 01:00:00 2011 From: lohmeyer at t10.org (T10 List Manager) Date: Tue, 28 Jun 2011 02:00:00 -0600 Subject: T10 Reflector Monthly Reminder Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 List Manager * This is an automatic monthly posting to the T10 Reflector. If you receive this message, it means that you are subscribed to the T10 Reflector email list. The T10 Reflector is provided by the SCSI Trade Association and maintained by LSI Corp. This reflector exists to discuss INCITS T10 Technical Committee issues and to disseminate T10-related information (minutes, meeting notices, etc.). --------------------------------------------------------------------------- You do not need to be an INCITS T10 Technical Committee member to use this reflector, however you must agree to: * read the INCITS Patent Policy and the INCITS Antitrust Guidelines * acknowledge that the activities of the T10 Technical Committee are governed by the INCITS policies and procedures as specified in the reference documents RD-1 and RD-2 * acknowledge that draft documents may change at any time, without notice. The INCITS Patent Policy, the INCITS Antitrust Guidelines, the RD-1, and the RD-2 are all available on the www.incits.org web site. If you do not agree to the above conditions, then you must unsubscribe to this reflector. --------------------------------------------------------------------------- T10 Reflector is not intended to carry commercial traffic. People who post advertisements, job offers, etc. will be removed from the reflector. Please visit http://www.t10.org/t10r.htm for instructions on subscribing, unsubscribing, or searching the T10 Reflector archives. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From lohmeyer at t10.org Tue Jun 28 14:17:48 2011 From: lohmeyer at t10.org (John Lohmeyer) Date: Tue, 28 Jun 2011 15:17:48 -0600 Subject: Fwd: Announcement for Aug. SOP F2F meeting. Message-ID: Formatted message: HTML-formatted message Attachment #1: cb1a52.jpg Forwarded for Mike Fitzpatrick: Toshiba is hosting a T10 SOP and PQI face-to-face meeting on August 15, 2011 right outside the San Jose Airport as follows: Date: Monday, August 15th from 9:00 AM to 7:00 PM PDT Location: DoubleTree by Hilton San Jose 2050 Gateway Place, San Jose, CA 95110 www.sanjose.doubletree.com | Facebook | Twitter | http://sanjosedoubletreehotel.com/>Blog [] The hotel is the same venue as the T13 meetings that will be held Tuesday - Thursday. There is no room block for this meeting so you can stay at any hotel of your choice. Any questions, please let me know. Thanks, Mike Fitzpatrick Toshiba From alvin.cox at seagate.com Wed Jun 29 12:23:15 2011 From: alvin.cox at seagate.com (Alvin Cox) Date: Wed, 29 Jun 2011 14:23:15 -0500 Subject: Reminder: SAS PHY WG conference call, 10:00 am CDT, June 30, 2011 Message-ID: Formatted message: HTML-formatted message Agenda: SSC requirements: How much SSC is needed? [Olawsky] AC coupling for receiver only [Seidel] Connector updates Channel updates New items Toll Free Dial in Number: (877)810-9442 International Access/Caller Paid Dial In Number: (636)651-3190 PARTICIPANT CODE: 3243413 Webex information: Topic: SAS PHY WG Date: Thursday, June 30, 2011 Time: 10:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 826 515 680 Meeting Password: newsas ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://seagate.webex.com/seagate/j.php?ED=90748572&UID=0&PW=NY2I0MTAzOTM5&RT =MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: newsas 4. Click "Join". To view in other time zones or languages, please click the link: https://seagate.webex.com/seagate/j.php?ED=90748572&UID=0&PW=NY2I0MTAzOTM5&OR T=MiM3 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://seagate.webex.com/seagate/mc 2. On the left navigation bar, click "Support". To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://seagate.webex.com/seagate/j.php?ED=90748572&UID=0&ICS=MRS2&LD=1&RD=2& ST=1&SHA2=SVyTzTdCGzSIxsgaH07Ohz1skP261RTOA-QjHZRNW6c=&RT=MiM3 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://seagate.webex.com/seagate/meetingcenter/mcsetup.php From Tim_Symons at pmc-sierra.com Wed Jun 29 15:21:36 2011 From: Tim_Symons at pmc-sierra.com (Tim Symons) Date: Wed, 29 Jun 2011 15:21:36 -0700 Subject: 11-292r0 : PQI draft 0 candidate posted Message-ID: Formatted message: HTML-formatted message To fellow members of the SOP/PQI working group: 11-292r0 was posted on Tuesday 28th June and is the revision that follows 11-157r9. Document 11-292r0 includes the changes recommended by the SOP/PQI working group on Monday 27th June. Please review document 11-292r0 as this will be proposed to become PQI draft rev0 at the face to face meeting on 12th July. When we have a draft 0 this will enable new proposals and concepts to be brought forward that can reference against a consistent baseline document. Regards Tim. Tim Symons Principal Engineer, PMC-Sierra Ltd. Cell: 778 998 5025 E-mail Tim_Symons at pmc-sierra.com