T10/05-126r0 Voting Results on T10 Letter Ballot 05-125r0 on Forwarding SAS-1.1 to First Public Review Ballot closed: 2005/04/19 12:00 noon MDT Organization Name S Vote Add'l Info --------------------------------- -------------------- - ---- ---------- Adaptec, Inc. Tim Symons P Yes Agilent Technologies Pat Thaler P Yes Amphenol Interconnect Michael Wingard P Yes Broadcom Corp. Paul Griffith P Yes Brocade Robert Snively P Abs Cmnts Cisco Systems, Inc. Claudio DeSanti P Abs Cmnts CNT David Peterson P Yes Crossroads Systems, Inc. DNV Dallas Semiconductor James A. Lott, Jr. P Yes Dell, Inc. Kevin Marks P No Cmnts EMC Corp. David Black A Yes Emulex Robert H. Nixon P No Cmnts ENDL Ralph O. Weber P Yes FCI Douglas Wagner P Yes Foxconn Electronics Elwood Parsons P Yes Fujitsu Mike Fitzpatrick P Yes General Dynamics Nathan Hastad P Yes Hewlett Packard Co. Rob Elliott P No Cmnts Hitachi Cable Manchester Zane Daggett P Yes Hitachi Global Storage Tech. Dan Colegrove P Yes IBM Corp. George O. Penokie P No Cmnts Intel Corp. Robert Sheffield P No Cmnts Iomega Corp. David Hawks P Yes Lexar Media, Inc. Martin Furuhjelm A Yes LSI Logic Corp. John Lohmeyer P No Cmnts Maxtor Corp. Mark Evans P No Cmnts Microsoft Corp. Jeff Mastro A Yes Molex Inc. Jay Neer P No Cmnts Nvidia Corp. DNV Panasonic Technologies, Inc Terence J. Nelson P Yes Philips Electronics William P. McFerrin P Yes Pivot3, Inc. Bill Galloway P Yes PMC-Sierra Bill Lye A Yes Cmnts QLogic Corp. Craig W. Carlson A Yes Cmnts Quantum Corp. Paul Entzel P Yes Seagate Technology Gerald Houlder P No Cmnts Sierra Logic, Inc. William Martin P Yes Cmnts Storage Technology Corp. Erich Oetting P Yes Sun Microsystems, Inc. Vit Novak P Yes Texas Instruments Paul D. Aloisi P Yes Toshiba Yutaka Arakawa P Yes TycoElectronics Ashlie Fan P No Cmnts Veritas Software Roger Cummings P Abs Cmnts Vitesse Semiconductor Gregory Tabor P Yes Western Digital Curtis Stevens P Yes Xiotech Corp. Jeff Williams P Yes Ballot totals: (31:10:3:2=46) 31 Yes 10 No 3 Abstain 2 Organization(s) did not vote 46 Total voting organizations 16 Ballot(s) included comments This 2/3rds majority ballot passed. 31 Yes are more than half the membership eligible to vote minus abstentions [greater than 21] AND 31 Yes are at least 28 (2/3rds of those voting, excluding abstentions [41]) AND 31 Yes are equal to or exceed a quorum [15] Key: P Voter is principal member A Voter is alternate member Abs Abstain vote DNV Organization did not vote Cmnts Comments were included with ballot NoCmnts No comments were included with a vote that requires comments ************************************************************** Comments attached to Abs ballot from Robert Snively of Brocade: This is outside the area of interest of Brocade Communications ************************************************************** Comments attached to Abs ballot from Claudio DeSanti of Cisco Systems, Inc.: I don't know enough this technology. ************************************************************** Comments attached to No ballot from Kevin Marks of Dell, Inc.: DELL comment number 1 Page=40 Subtype=Highlight Author=Kevin_Marks Comment= 1 Scope Figure 1 - SCSI document relationships Change "Protocols" to "SCSI Transport Protocols" DELL comment number 2 Page=40 Subtype=Highlight Author=Kevin_Marks Comment= 1 Scope In Figure 1 - SCSI document relationships Change "Primary command set" to "Primary Command Set" DELL comment number 3 Page=41 Subtype=Highlight Author=Kevin_Marks Comment= 1 Scope In Figure 2 - ATA document relationships Change "Primary command set" to "Primary Command Set" DELL comment number 4 Page=41 Subtype=Highlight Author=Kevin_Marks Comment= 1 Scope In Figure 2 - ATA document relationships Change "ATA/ATAPI register set (ATA/ATAPI-7 Volume 1)" to "ATA/ATAPI Logical register set (ATA/ATAPI-7 Volume 1)" DELL comment number 5 Page=43 Subtype=Highlight Author=Kevin_Marks Comment= 2.3 References under development Because of the inclusion of 05-107r1 (overlap command handling), does SAM-4 need to be included? DELL comment number 6 Page=43 Subtype=Highlight Author=Kevin_Marks Comment= 2.4 Other References Change "(SATA2-PHY)" to "(SATAII-PHY)" There is already enough industry confusion between SATA2 and SATAII. DELL comment number 7 Page=43 Subtype=Highlight Author=Kevin_Marks Comment= 2.4 Other references change "http://www.serialata.org" to "http://www.sata-io.org" DELL comment number 8 Page=43 Subtype=Highlight Author=Kevin_Marks Comment= 2.4 Other references Change "Internal Serial Attachment Connector" to "Unshielded Dual Port Serial Attachment Connector" DELL comment number 9 Page=43 Subtype=Highlight Author=Kevin_Marks Comment= 2.4 Other References Change "(SATA2-EXT)" to "(SATAII-EXT)" DELL comment number 10 Page=43 Subtype=Highlight Author=Kevin_Marks Comment= 2.4 Other References Change "(SATA2-PS)" to "(SATAII-PS)" DELL comment number 11 Page=43 Subtype=Highlight Author=Kevin_Marks Comment= 2.4 Other references for SFF-8484 change "Multi Lane Internal Serial Attachment Connector" to "Multi Lane Unshielded Serial Attachment Connector" DELL comment number 12 Page=46 Subtype=Highlight Author=Kevin_Marks Comment= 3.1.23 clock data recovery (CDR) change "The function is provided by the receiver circuit ..." to "A function provided by the receiver circuit ..." DELL comment number 13 Page=46 Subtype=StrikeOut Author=Kevin_Marks Comment= 3.131 connector Remove "Connectors may introduce physical disturbances to the transmission path due to impedance mismatch, crosstalk, etc. These disturbances may introduce jitter and other forms of signal degradation under certain conditions." Although true, does not belong in the definition of connector.. DELL comment number 14 Page=50 Subtype=Highlight Author=Kevin_Marks Comment= 3.1.88 identification sequence change "See 4.4." to "See 4.1.2" or "See 7.9" This is where the identification sequence is first talked about. DELL comment number 15 Page=50 Subtype=Highlight Author=Kevin_Marks Comment= 3.1.98 idle dword change (Global) "vendor-specific" to "vendor specific" vendor specific is a keyword and does not contain a dash. Through out draft the dash is used. DELL comment number 16 Page=52 Subtype=Highlight Author=Kevin_Marks Comment= 3.1.118 media Change "...part of connectors." to "...part of connectors or a plural of medium." Because the word media is used multiple times in the power conditions state machine, .i.e. rotating media. This may additionally add a definition for medium as "medium: The material on which data is stored (e.g., a magnetic disk)." DELL comment number 17 Page=54 Subtype=Highlight Author=Kevin_Marks Comment= 3.1.164 SAS Address Change "unique name assigned" to" "unique name or identifier assigned" SAS Ports do not have names, only identifiers. DELL comment number 18 Page=55 Subtype=Highlight Author=Kevin_Marks Comment= 3.1.188 SCSI port Change" 3.1.188 SCSI port: A SCSI initiator port or a SCSI target port. See SAM-3." to "3.1.188 SCSI port: A SCSI initiator port, a SCSI target port or a SCSI target/initiator port. See SAM-3." DELL comment number 19 Page=55 Subtype=Highlight Author=Kevin_Marks Comment= 3.1.182 SATA port selector: Change "(see SATA2-PS)." to "(see SATAII-PS)." DELL comment number 20 Page=56 Subtype=Highlight Author=Kevin_Marks Comment= 3.1.196 Serial Management Protocol (SMP) Change "... used by SAS devices to communicate management information with other SAS devices in a SAS domain." to ".. used by SMP initiator ports to communicate with SMP target ports for the purpose of communicating management information in a SAS domain." DELL comment number 21 Page=70 Subtype=Text Author=Kevin_Marks Comment= Figure 9 - State machine conventions Many of the state machines in the standard contain only a single state. When the State designator:State_Name format is used, the text never references this state, and a search for this State designator:State_Name would only hit the state machine state on the figure. I propose that for state machines that only have a single state, that the state name be left off and a sentence that follows be added to the paragraph after Figure 9. "For state machines that only contain a single state, only the state designator may be used." DELL comment number 22 Page=71 Subtype=Highlight Author=Kevin_Marks Comment= 3.7 Bit and byte ordering Change "NOTE 5 - SATA numbers bits within fields the same as this standard, but uses little-endian byte ordering." to "NOTE 5 - SATA numbers bits within fields are the same as in this standard, but uses little-endian byte ordering. DELL comment number 23 Page=73 Subtype=Highlight Author=Kevin_Marks Comment= 4.1 Architecture Change ".... one SMP port." to "... one SMP target port." DELL comment number 24 Page=77 Subtype=StrikeOut Author=Kevin_Marks Comment= 4.1.2 Physical links and phys Second paragraph, first sentence after Figure 12. Remove "(i.e., the transceiver)" The phy consists of more that the transceiver. DELL comment number 25 Page=90 Subtype=Highlight Author=Kevin_Marks Comment= 4.1.9 Pathways 1st Paragraph, 3rd Sentence change "phy, there are multiple potential pathways, each" to "phy, there may be multiple potential pathways, each" DELL comment number 26 Page=91 Subtype=Highlight Author=Kevin_Marks Comment= 4.1.9 Pathways Last Paragraph change "A partial pathway is blocked when path resources it requires are held by another partial pathway (see 7.12)." to "A partial pathway is blocked when path resources it requires are held by another partial pathway or pathway (see 7.12)." DELL comment number 27 Page=91 Subtype=Highlight Author=Kevin_Marks Comment= 4.1.10 Connections 5th Paragraph,1st Sentence Change "One connection may be active on a physical link at a time" to "Only one connection may be active on a physical link at a time." DELL comment number 28 Page=93 Subtype=Highlight Author=Kevin_Marks Comment= 4.2.1 Names and identifiers overview 1st Sentence Change "Device names are worldwide unique names for devices within a transport protocol (see SAM-3)." to "Device names are worldwide unique names for devices within a SCSI transport protocol (see SAM-3)." DELL comment number 29 Page=93 Subtype=StrikeOut Author=Kevin_Marks Comment= 4.2.1 Names and identifiers overview. Remove 2nd Sentence "Port names are worldwide unique names for ports within a transport protocol." Since port names are not used in SAS, why define their uniqueness in relation to SAM-3. DELL comment number 30 Page=95 Subtype=Highlight Author=Kevin_Marks Comment= 4.2.5 Port names 1st Sentence Change "SCSI" to "the SCSI Architectural Model" or "SAM-3" DELL comment number 31 Page=99 Subtype=Highlight Author=Kevin_Marks Comment= Figure 32 Change "SSP_TC (transmit credit) state machine" to "SSP_TC (transmit credit control) state machine" DELL comment number 32 Page=99 Subtype=Highlight Author=Kevin_Marks Comment= Figure 32 Change "SSP_TF (transmit frame) state machine" to "SSP_TF (transmit frame control) state machine" DELL comment number 33 Page=111 Subtype=Highlight Author=Kevin_Marks Comment= 4.6.2 Expander ports 5 Paragraph, 1st Sentence Change "with a peripheral device type of SCSI enclosure services (SES))." to "with a peripheral device type of enclosure services device (SES))." To match SPC-3 type 0dh. DELL comment number 34 Page=111 Subtype=Highlight Author=Kevin_Marks Comment= 4.6.2 Expander ports 6th Paragraph, 1st Sentence Change "... internal SMP port using ..." to "... internal SMP target port using ..." DELL comment number 35 Page=111 Subtype=StrikeOut Author=Kevin_Marks Comment= 4.6.3 Expander connection manager (EMC) b) list Remove "addressing" DELL comment number 36 Page=116 Subtype=Highlight Author=Kevin_Marks Comment= Table 12 - ECM to expander phy confirmations (part 2 of 2) Message Row - (Arb Reject (Bad Destination) change "...the EM has not chosen to return Arb..." to "...the ECM has not chosen to return Arb..." DELL comment number 37 Page=118 Subtype=Highlight Author=Kevin_Marks Comment= Table 15 - Expander phy to BPP requests Table Row - Broadcast Event Notify (Phy Not Ready) Change "or because a virtual phy has been disabled (see 10.4.3.10). See 7.11." to "or because a phy or virtual phy has been disabled (see 10.4.3.10). See 7.11." I do not believe that when a phy is disabled via SMP PHY CONTROL, that it would transition to the SP0:OOB_COMINIT state. I would think that the SP state machine would be stopped, waiting on a link or hard reset to re-enable it. DELL comment number 38 Page=122 Subtype=Highlight Author=Kevin_Marks Comment= 4.7.1 Discovery process overview Last Sentence Change "The discover process may be aborted prior to completion if there is an indication that it may be based on incorrect information (e.g., arrival of a BROADCAST (CHANGE))." to "The discover process may be aborted and need to be restarted prior to completion if there is an indication that it may be based on incorrect information (e.g., arrival of a BROADCAST (CHANGE))." DELL comment number 39 Page=122 Subtype=Text Author=Kevin_Marks Comment=Unmarked set by Kevin_Marks DELL comment number 40 Page=123 Subtype=Highlight Author=Kevin_Marks Comment= 4.7.3 discover process optimization 5th Paragraph, list a) "a) when an OPEN_REJECT (NO DESTINATION) is received for a connection request to a SAS address that is expected to be in an existing expander device route table;" Add an example for what is an expected SAS address to be present or remove a). This whole section is so vendor specific, that an example might help. DELL comment number 41 Page=123 Subtype=Highlight Author=Kevin_Marks Comment= 4.7.3 discover process optimization 6th Paragraph, 1st Sentence "...detects an inconsistency in the expander route tables..." What is defined as an inconsistency, add example? DELL comment number 42 Page=132 Subtype=Highlight Author=Kevin_Marks Comment= Figure 50 - SAS internal cabled environments Top figure Change "SATA-style signal cable receptacle" to "SATA-style signal cable receptacle connector" DELL comment number 43 Page=132 Subtype=Highlight Author=Kevin_Marks Comment= Figure 50 - SAS internal cabled environments Bottom figure Change "SATA-style signal cable receptacle" to "SATA-style signal cable receptacle connector" DELL comment number 44 Page=132 Subtype=Highlight Author=Kevin_Marks Comment= Figure 50 - SAS internal cabled environments Bottom figure Change "SATA-style signal cable receptacle" to "SATA-style signal cable receptacle connector" DELL comment number 45 Page=133 Subtype=Highlight Author=Kevin_Marks Comment= Figure 52 - SAS external cabled environment change "(SAS external cable connects the Tx signal pins to the Rx signal pins on each physical link)" to "(the cable connects the Tx signal pins to the Rx signal pins on each physical link)" This removes reference to whether it is compact or not. DELL comment number 46 Page=133 Subtype=Highlight Author=Kevin_Marks Comment= Figure 53 - Internal wide cabled environment - controller to backplane - symmetric cable change "(symmetric SAS internal wide cable connects the Tx signal pins to the Rx signal pins within each physical link)" to "(the cable connects the Tx signal pins to the Rx signal pins within each physical link)" This removes reference to whether it is compact or not. DELL comment number 47 Page=133 Subtype=Highlight Author=Kevin_Marks Comment= Figure 53 - Internal wide cabled environment - controller to backplane - symmetric cable under Controller change "SAS internal wide plug or internal compact wide receptacle (4 physical links)" to "SAS internal wide plug or internal compact wide receptacle connector (4 physical links)" DELL comment number 48 Page=134 Subtype=Highlight Author=Kevin_Marks Comment= Figure 54 - Internal wide cabled environment - controller to controller - symmetric cable change "(SAS internal wide cable connects the Tx signal pins to the Rx signal pins within each physical link)" to "(the cable connects the Tx signal pins to the Rx signal pins within each physical link)" This removes reference to whether it is compact or not. DELL comment number 49 Page=139 Subtype=Highlight Author=Kevin_Marks Comment= Table 23 - SAS internal connector pin assignments Note c Change "(see SATA2-EXT)." to "(see SATAII-EXT)" DELL comment number 50 Page=142 Subtype=StrikeOut Author=Kevin_Marks Comment= 5.2.3.3.5 SAS external compact cable plug connector 1st Sentence Remove "with latch" Since no other option is defined in SFF-8088. DELL comment number 51 Page=142 Subtype=Highlight Author=Kevin_Marks Comment= 5.2.3.3.5 SAS external compact cable plug connector 2nd Sentence change "SFF-8086 defines the circuit board, which is common ...." to "SFF-8086 defines the circuit board layout, which is common ...." DELL comment number 52 Page=142 Subtype=Text Author=Kevin_Marks Comment= 5.2.3.3.5 SAS external compact cable plug connector SFF-8086 define 4 different circuit board layout sizes(26,36,50,68). No where in the SAS external compact cable plug or receptacle sections does it indicate that the 26 ckt version is used. It can only be inferred by looking at table 25, adding up A1-A13 and B1-B13. Need to add that it uses 26 ckt version in 8086. DELL comment number 53 Page=142 Subtype=StrikeOut Author=Kevin_Marks Comment= 5.2.3.3.5 SAS external compact cable plug connector 2nd paragraph, 1st and 2nd sentences Remove "The SAS external compact cable plug connector shall not include keys and may include key slots. Key slots are not defined by this standard." As keying is defined. DELL comment number 54 Page=143 Subtype=Text Author=Kevin_Marks Comment= Figure 63 - SAS external compact cable plug connector Add text indicating A1 is on bottom, or add B1 indicator coming from top. DELL comment number 55 Page=143 Subtype=Highlight Author=Kevin_Marks Comment= 5.2.3.3.6 SAS external compact receptacle connector 1st paragraph, 2nd sentence change "... interface (the receptacle body is common to both internal and external connectors)" to "... interface layout (the receptacle body is common to both internal and external connectors)" DELL comment number 56 Page=143 Subtype=Text Author=Kevin_Marks Comment= 5.2.3.3.6 SAS external compact receptacle connector SFF-8086 define 4 different mating interface layout sizes(26,36,50,68). No where in the SAS external compact cable plug or receptacle sections does it indicate that the 26 ckt version is used. It can only be inferred by looking at table 25, adding up A1-A13 and B1-B13. Need to add that it uses 26 ckt version in 8086. DELL comment number 57 Page=143 Subtype=Highlight Author=Kevin_Marks Comment= 5.2.3.3.6 SAS external compact receptacle connector Insert two paragraphs below before "Table 25 (see 5.2.3.3.7) defines the pin assignments." text to be inserted: A SAS external compact receptacle connector may be used by one or more SAS devices (e.g., one SAS device using "physical links 0 and 3, another using physical link 1, and a third using physical link 2). A SAS external compact receptacle connector shall be used by only one expander device at a time, and all physical links shallbe used by the same expander port (i.e., all the expander phys shall have the same routing attribute (e.g., subtractive or table) (see 4.6.2))." DELL comment number 58 Page=143 Subtype=StrikeOut Author=Kevin_Marks Comment= 5.2.3.3.6 SAS external compact receptacle connector 2nd Paragraph, 1st and 2nd Sentence Remove "The SAS external compact receptacle connector shall not include keys and may include key slots. Key slots are not defined by this standard." Keying is defined. DELL comment number 59 Page=144 Subtype=Text Author=Kevin_Marks Comment= Figure 64 - SAS external compact receptacle connector Add text indicating A1 is on bottom, or add B1 indicator coming from top. DELL comment number 60 Page=145 Subtype=Text Author=Kevin_Marks Comment=Update per T10/05-138r0. DELL comment number 61 Page=145 Subtype=Text Author=Kevin_Marks Comment= SFF-8088 currently defines 5 different key and slot locations. Need to explicitly add which locations are used for each version. 3 on receptacle 1 for table route or enclosure out port on receptacle and 1-3 for plug 5 for subtractive or enclosure in port on receptacle and 3-5 for plug DELL comment number 62 Page=146 Subtype=Text Author=Kevin_Marks Comment= Figure 65 - SAS external compact connector keys for end devices Remove plug picture, and add text above figure that table (enclosure out port) and subtractive (enclosure in port) plug both plug into end device receptacle. Suggest putting end device figure last, so that the two subtractive and table plugs are defined. DELL comment number 63 Page=146 Subtype=Text Author=Kevin_Marks Comment= Figure 66 - SAS external compact connector keys for expander device table routing phys Receptacle only needs key in position 1. DELL comment number 64 Page=146 Subtype=Highlight Author=Kevin_Marks Comment= 5.2.3.3.8 External compact connector keying 1st Sentence after Figure 65. Change "...used by expander device table routing phys, and the key slots..." to "...used by expander device table routing phys (e.g. Enclosure out port), and the key slots..." DELL comment number 65 Page=147 Subtype=Text Author=Kevin_Marks Comment= Figure 67 - SAS external compact connector keys for expander device subtractive routing phys Receptacle only needs key in position 5. DELL comment number 66 Page=147 Subtype=Highlight Author=Kevin_Marks Comment= 5.2.3.3.8 External compact connector keying 1st Sentence after Figure 66. change "....used by expander device subtractive routing phys, and the key slots..." to "....used by expander device subtractive routing phys (e.g. Enclosure in port), and the key slots..." DELL comment number 67 Page=147 Subtype=Highlight Author=Kevin_Marks Comment= 5.2.3.4.1 SAS internal wide connectors overview 2nd Paragraph, 1st Sentence change "...expander devices with external ports shall use..." to "...expander devices with internall ports shall use..." DELL comment number 68 Page=147 Subtype=Text Author=Kevin_Marks Comment= Reject proposed changes in T10/05-139r0 unless modified to change: 1. If using Alternate Table 26Z -- Controller SAS internal pin assignments and physical link usage - does not define pin assignments, only signal usage for link widths. 2. In the statement "The use of the sideband signals by a backplane is vendor-specific. One implementation of the sideband signals by a backplane is an SGPIO target interface (see SFF-8485). Other implementations shall be compatible with the signal levels defined in SFF-8485." - SFF-8485 does not currently define a mapping for the external compact version of the cable, and because there are 8 sidebands, the mapping is not obvious. Additionally, I question the "shall be compatible with the signal levels", because the mapping of the signals to sidebands in SFF-8485 is in an informative section. 3. If removing the tables defining the signal to pin mapping and relying on the cabling diagrams, then the external cable should use the same delivery style, i.e. remove table and add diagram of cabling. 4. Add that the internal compact wide cable plug connector uses the 36 pin version of SFF-8086 and the circuit board layout is common, and not the circuit board. 5. Add that the internal compact wide receptacle connector uses the 36 pin version of SFF-8086 and the the receptacle mating interface layout is common, and not the receptacle mating interface. DELL comment number 69 Page=150 Subtype=Text Author=Kevin_Marks Comment= 5.2.3.4.5 SAS internal compact wide cable plug connector SFF-8086 define 4 different circuit board layout sizes (26,36,50,68). No where in the SAS external compact cable plug or receptacle sections does it indicate that the 36 ckt version is used. It can only be inferred by looking at table 28, adding up A1-A18 and B1-B18. Need to add that it uses 36 ckt version in 8086. DELL comment number 70 Page=150 Subtype=Highlight Author=Kevin_Marks Comment= 5.2.3.4.5 SAS internal compact wide cable plug connector 1st paragraph, 2nd sentence change "SFF-8086 defines the circuit board, which is common to both internal...." to "SFF-8086 defines the circuit board layout, which is common to both internal...." DELL comment number 71 Page=151 Subtype=Text Author=Kevin_Marks Comment= 5.2.3.4.6 SAS internal compact wide receptacle connector SFF-8086 define 4 different receptacle mating interface layout sizes(26,36,50,68). No where in the SAS internal compact wide cable plug or receptacle sections does it indicate that the 36 ckt version is used. It can only be inferred by looking at table 28, adding up A1-A18 and B1-B18. Need to add that it uses 36 ckt version in 8086. DELL comment number 72 Page=151 Subtype=Highlight Author=Kevin_Marks Comment= 5.2.3.4.6 SAS internal compact wide receptacle connector 1st paragraph, 2nd sentence change "SFF-8086 defines the receptacle mating interface, which is common to...." to "SFF-8086 defines the receptacle mating interface layout, which is common to...." DELL comment number 73 Page=151 Subtype=Text Author=Kevin_Marks Comment= Figure 70 - SAS internal compact wide cable plug connector Add text indicating A1 is on bottom, or add B1 indicator coming from top. DELL comment number 74 Page=152 Subtype=Text Author=Kevin_Marks Comment= Figure 71 - SAS internal compact wide receptacle connector Add text indicating A1 is on bottom, or add B1 indicator coming from top. DELL comment number 75 Page=156 Subtype=Highlight Author=Kevin_Marks Comment= Figure 72 - SAS single-port internal cable assembly and destination pin assignments on SAS initiator device or expander device Change "GROUND 7 RP+ 6 RP- 5 GROUND 4 TP- 3 TP+ 2 GROUND 1" to "GROUND 7 RX+ 6 RX- 5 GROUND 4 TX- 3 TX+ 2 GROUND 1" DELL comment number 76 Page=157 Subtype=Highlight Author=Kevin_Marks Comment= Figure 73 - SAS dual-port internal cable assembly and destination pin assignments On both SAS initiator device or expander device Change "GROUND 7 RP+ 6 RP- 5 GROUND 4 TP- 3 TP+ 2 GROUND 1" to "GROUND 7 RX+ 6 RX- 5 GROUND 4 TX- 3 TX+ 2 GROUND 1" DELL comment number 77 Page=158 Subtype=Text Author=Kevin_Marks Comment= 5.2.4.2 SAS external cables If T10/05-139r0 is approved, would like to see diagrams of signal pin mapping for the 3 defined external cables a),b) and c), like figure 74. DELL comment number 78 Page=158 Subtype=Text Author=Kevin_Marks Comment= 5.2.4.3.1 SAS internal wide cables overview If T10/05-139r0 is approved, would like to see a diagram of signal pin mapping for option c) under symmetric cables, similar to figure 74. DELL comment number 79 Page=162 Subtype=Highlight Author=Kevin_Marks Comment= Figure 77 - SAS internal wide cable with SAS internal compact wide cable plug connectors attaching controller to controller Whether the sidebands are correct or not, the text for the sideband should be in black and not in italic. DELL comment number 80 Page=167 Subtype=Text Author=Kevin_Marks Comment= Figure 82 - SAS internal wide cable with SAS internal compact wide cable plug connectors with two key slots this figure should be added to the external keying section. This should be the only keyed version of the cable. One end fits end devices or subtractive and the other end fits end device or table. DELL comment number 81 Page=167 Subtype=StrikeOut Author=Kevin_Marks Comment= 5.2.4.3.5 SAS internal compact wide cable keying Remove all of section 5.2.4.3.5 or change all internal "references" to "external", as on further review, this section looks like it is for the external keying. Phy working group did not ask for keying on internal cables and additionaly plugs are the external versions DELL comment number 82 Page=168 Subtype=StrikeOut Author=Kevin_Marks Comment= device subtractive routing phys. The cable should include the SAS icons described in figure M.7 at each end (see M.2.3). " and Figure 93. This is a continuation from previous cross-out DELL comment number 83 Page=184 Subtype=Highlight Author=Kevin_Marks Comment= 5.3.3 General electrical characteristics 5th Paragraph, b) list change "...levels (see SATA2-PHY) but..." to "...levels (see SATAII-PHY) but..." DELL comment number 84 Page=186 Subtype=Highlight Author=Kevin_Marks Comment= Table 36 - Receiver device general electrical characteristics In note a change "...V3 and SATA2-PHY)." to "...V3 and SATAII-PHY)." DELL comment number 85 Page=192 Subtype=Highlight Author=Kevin_Marks Comment= 5.3.7.3 Transmitter device signal output characteristics as measured with each test load Table 38 - Transmitter device signal output characteristics as measured with each test load at transmitter device compliance points IT and CT IT column for row: 1. Maximum peak to peak voltage (i.e., 2 x Z2) if a SATA device can be attached 2. Minimum eye opening (i.e., 2 x Z1), if a SATA device can be attached change "see SATA2-PHY" to "see SATAII-PHY" DELL comment number 86 Page=192 Subtype=Highlight Author=Kevin_Marks Comment= Table 38 - Transmitter device signal output characteristics as measured with each test load at transmitter device compliance points IT and CT In note g: change "...0) dwords (see SATA2-PHY)." to "...0) dwords (see SATAII-PHY)." DELL comment number 87 Page=192 Subtype=Highlight Author=Kevin_Marks Comment= 5.3.7.3 Transmitter device signal output characteristics as measured with each test load Table 38 - Transmitter device signal output characteristics as measured with each test load at transmitter device compliance points IT and CT IT column for row: "Minimum OOB burst amplitude d, if attaching a SATA device is supported" Change "225^f 225^g" to "see SATAII-PHY ^e" DELL comment number 88 Page=193 Subtype=Highlight Author=Kevin_Marks Comment= 5.3.7.5 Transmitter device signal output levels for OOB signals 1st sentence. change "...signal levels (see SATA2-PHY) during..." to "...signal levels (see SATAII-PHY) during..." DELL comment number 89 Page=193 Subtype=Highlight Author=Kevin_Marks Comment= 5.3.7.5 Transmitter device signal output levels for OOB signals 1st Paragraph, 5th Sentence Change "...COMINIT at SATA 1.0 signal levels..." to "...COMINIT at SATA Gen1i or Gen2i signal levels..." DELL comment number 90 Page=193 Subtype=Highlight Author=Kevin_Marks Comment= 5.3.7.5 Transmitter device signal output levels for OOB signals 3rd Paragraph, 1st Sentence Change "...voltage levels and repeat the OOB sequence." to "...voltage levels and restart the OOB sequence." DELL comment number 91 Page=194 Subtype=Highlight Author=Kevin_Marks Comment= 5.3.8.2 Delivered signal characteristics In Table 40 - Delivered signal characteristics as measured with the zero length test load at receiver device compliance points IR and CR (part 1 of 2) IR column, row - Maximum peak to peak voltage (i.e., 2 x Z2) if a SATA device is attached change "see SATA2-PHY" to "see SATAII-PHY" DELL comment number 92 Page=194 Subtype=Highlight Author=Kevin_Marks Comment= 5.3.8.2 Delivered signal characteristics In Table 40 - Delivered signal characteristics as measured with the zero length test load at receiver device compliance points IR and CR (part 1 of 2) Remove "or Gen1x levels" from Row "Minimum eye opening (i.e., 2 x Z1), if a SATA device using Gen1i or Gen1x levels is attached and the interconnect is characterized with the TCTF test load (see 5.3.2.3)" The SATAII, Electrical Specification does not define a usage model or allow for having the Gen1x or Gen2x phy electrical specification on a SATA device. DELL comment number 93 Page=194 Subtype=StrikeOut Author=Kevin_Marks Comment= 5.3.8.2 Delivered signal characteristics In Table 40 - Delivered signal characteristics as measured with the zero length test load at receiver device compliance points IR and CR (part 1 of 2) Remove row "Minimum eye opening (i.e., 2 x Z1), if a SATA device using Gen2x levels is attached and the interconnect is characterized with the TCTF test load (see 5.3.2.3)" The SATAII, Electrical Specification does not define a usage model or allow for having the Gen1x or Gen2x phy electrical specification on a SATA device. DELL comment number 94 Page=195 Subtype=Highlight Author=Kevin_Marks Comment= Table 40 - Delivered signal characteristics as measured with the zero length test load at receiver device compliance points IR and CR (part 2 of 2) In note g change "...ALIGN (0) dwords (see SATA2-PHY)." to "...ALIGN (0) dwords (see SATAII-PHY)." DELL comment number 95 Page=197 Subtype=Highlight Author=Kevin_Marks Comment= 5.3.9 Spread spectrum clocking 2nd Paragraph, 1st Sentence change "clocking (see ATA/ATAPI-7 V3 and SATA2-PHY)." to "clocking (see ATA/ATAPI-7 V3 and SATAII-PHY)." DELL comment number 96 Page=198 Subtype=Highlight Author=Kevin_Marks Comment= 5.4 READY LED signal electrical characteristics Note 15 change "....staggered spin-up disable (see SATA2-EXT). The output..." to "....staggered spin-up disable (see SATAII-EXT). The output..." DELL comment number 97 Page=207 Subtype=Highlight Author=Kevin_Marks Comment= Table 47 „ Control characters Make blue text black in table. DELL comment number 98 Page=208 Subtype=Highlight Author=Kevin_Marks Comment= Table 49 „ Delayed code violation example Make blue text black in table and not underlined. DELL comment number 99 Page=215 Subtype=Highlight Author=Kevin_Marks Comment= 6.6.4 Transmitting the SATA port selection signal 1st paragraph, 1st sentence Change "...the active phy (see SATA2-PS)." to "...the active phy (see SATAII-PS)." DELL comment number 100 Page=216 Subtype=Highlight Author=Kevin_Marks Comment= 6.7.2.1 SATA OOB sequence 1st paragraph, 2nd sentence Change "...and SATA2-PHY for detailed requirements." to "...and SATAII-PHY for detailed requirements." DELL comment number 101 Page=216 Subtype=Highlight Author=Kevin_Marks Comment= Figure 109 „ SATA OOB sequence Seems to be missing SATA device Calibrate and COMWAKE, as this is part of the SATA OOB. DELL comment number 102 Page=217 Subtype=Highlight Author=Kevin_Marks Comment= 6.7.2.2 SATA speed negotiation sequence 1st Paragraph, 2nd Sentence change "...and SATA2-PHY for detailed requirements." to "...and SATAII-PHY for detailed requirements." DELL comment number 103 Page=217 Subtype=StrikeOut Author=Kevin_Marks Comment= 6.7.3 SAS to SATA phy reset sequence 5th Paragraph, 2nd Sentence Remove "initiate" from sentence. DELL comment number 104 Page=223 Subtype=Highlight Author=Kevin_Marks Comment= 6.7.4.2 SAS speed negotiation sequence 1st Paragraph, 2nd Sentence after Table 114 Change "...reported in the PHY RESET PROBLEM field in..." to "...reported in the PHY RESET PROBLEM COUNT field in..." DELL comment number 105 Page=224 Subtype=Highlight Author=Kevin_Marks Comment= 6.7.5 Phy reset sequence after devices are attached 3rd Sentence, B) in a,b,c list change "b) SAS initiator phys should originate a new phy reset sequence after every hot-plug timeout; and" to ""b) SAS initiator phys should originate a new phy reset sequence after every hot-plug timeout, if implemented; and" hot-plug timeout timer is optional in SAS initiators. DELL comment number 106 Page=228 Subtype=Text Author=Kevin_Marks Comment= Figure 117 - SP (phy layer) state machine - OOB sequence states The SP7:OOB_AwaitCOMSAS state in Figure 117 is missing the SATA Spinup Hold confirmation to the link layer, based on text for transition to SP26:SATA_SpinupHold. I do not believe the text is correct, the SATA Spinup Hold confirmation to the link layer belongs in the entry to the SP26:SATA_SpinupHold state as is currently indicated in Figure 121. DELL comment number 107 Page=231 Subtype=Highlight Author=Kevin_Marks Comment= 6.8.3.9.2 Transition SP7:OOB_AwaitCOMSAS to SP2:OOB_NoCOMSASTimeout 1st Sentence Change "This transition shall occur if the phy does not support SATA and the COMSAS Detect Timeout timer expires." to "This transition shall occur if the phy does not support attachment to a SATA device and the COMSAS Detect Timeout timer expires." DELL comment number 108 Page=232 Subtype=Highlight Author=Kevin_Marks Comment= 6.8.3.9.4 Transition SP7:OOB_AwaitCOMSAS to SP16:SATA_COMWAKE 1st Sentence, a) in a,b,c list change "a) the phy supports attachment to SATA devices;" to "a) the phy supports attachment to a SATA device;" DELL comment number 109 Page=232 Subtype=Highlight Author=Kevin_Marks Comment= 6.8.3.9.5 Transition SP7:OOB_AwaitCOMSAS to SP26:SATA _SpinupHold 1st Paragraph, 1st Sentence Change "This state shall send a SATA Spinup Hold confirmation to the link layer and perform this transition if." to "This transition shall occur if:" The SATA Spinup Hold confirmation to the link layer belongs in the entry in to SP26:SATA_SpinupHold. If this is not accepted, need a colon after if. DELL comment number 110 Page=234 Subtype=Highlight Author=Kevin_Marks Comment= 6.8.4.2.3 Transition SP8:SAS_Start to SP9:SAS_RateNotSupported 1st Sentence change "This transition shall occur after the RCDT timer expires if the current speed negotiation window rate is not supported." to "This transition shall occur after the RCDT timer expires and the current speed negotiation window rate is not supported." DELL comment number 111 Page=234 Subtype=Highlight Author=Kevin_Marks Comment= 6.8.4.2.4 Transition SP8:SAS_Start to SP10:SAS_AwaitALIGN 1st Sentence change "This transition shall occur after the RCDT timer expires if the current speed negotiation window rate is supported." to "This transition shall occur after the RCDT timer expires and the current speed negotiation window rate is supported." DELL comment number 112 Page=243 Subtype=Highlight Author=Kevin_Marks Comment= 6.8.7.1 State description 1st Paragraph, 2st Sentence change if not removed by previous comment. "...upon detection of a COMSAS detect timeout if the phy supports SATA, the phy supports SATA spinup hold, and..." to "...upon detection of a COMSAS detect timeout and the phy supports attachment to a SATA device, the phy supports SATA spinup hold, and..." DELL comment number 113 Page=243 Subtype=Text Author=Kevin_Marks Comment= Figure 121 - SP (phy layer) state machine - SATA spinup hold state Based on text in the OOB state machine, the SATA Spinup Hold confirmation to the link layer belongs in SP7:OOB_AwaitCOMSAS. I believe this is incorrect and is correct as shown. DELL comment number 114 Page=243 Subtype=StrikeOut Author=Kevin_Marks Comment= 6.8.7.1 State description 1st Paragraph, 2nd Sentence Remove "This state shall be entered from the SP7:OOB_AwaitCOMSAS state upon detection of a COMSAS detect timeout if the phy supports SATA, the phy supports SATA spinup hold, and the MgmtReset state machine variable is set to zero." This sentence proposed for removal is redundant, and described in the SP7:OOB_AwaitCOMSAS to SP26:SATA_SpinupHold state transition. Add "This state shall send a SATA Spinup Hold confirmation to the link layer." DELL comment number 115 Page=243 Subtype=Highlight Author=Kevin_Marks Comment= 6.8.7.2 Transition SP26:SATA_SpinupHold to SP0:OOB_COMINIT 1st Paragraph,2nd Sentence change "...a Management Reset Request from the..." to "...a Management Reset request from the..." DELL comment number 116 Page=249 Subtype=Highlight Author=Kevin_Marks Comment= 6.10 Spin-up 2nd Paragraph, 1st sentence change "...SATA spin-up rules (see ATA/ATAPI-7 V3 and SATA2-EXT)." to "...SATA spin-up rules (see ATA/ATAPI-7 V3 and SATAII-EXT)." DELL comment number 117 Page=249 Subtype=Highlight Author=Kevin_Marks Comment= 6.10 Spin-up Note 19 Change "NOTE 19 - Enclosures supporting both SATA devices and SAS target devices may need to sequence power to each attached device to avoid excessive power consumption during power on, since the SATA devices may spin-up automatically after power on." to "NOTE 19 - Enclosures supporting both SATA devices and SAS target devices may need to sequence power to each attached device to avoid excessive power consumption during power on, since the SATA devices may spin-up automatically after power on if staggered spin-up is not implemented (see SATAII-EXT)." DELL comment number 118 Page=249 Subtype=Highlight Author=Kevin_Marks Comment= 6.10 Spin-up 2nd Paragraph, 1st Sentence "If a SAS target device supporting SATA does not receive COMSAS during the reset sequence, it shall follow SATA spin-up rules (see ATA/ATAPI-7 V3 and SATA2-EXT)." Sentence seems confusing. What is a SAS target device supporting SATA? Is this a device supporting STP target protocol. Clarify or remove sentence. DELL comment number 119 Page=265 Subtype=Highlight Author=Kevin_Marks Comment= 7.2.5.4 BROADCAST 4th Paragraph,1st Sentence after Table 71. change "....logical units with peripheral device types of SCSI enclosure services (SES) in the SAS domain." to "....logical units with peripheral device type of enclosure services device (SES) in the SAS domain." The peripheral device type for SES is enclosure services device. DELL comment number 120 Page=267 Subtype=Highlight Author=Kevin_Marks Comment= 7.2.5.9 NOTIFY Note 22 after 2nd Paragraph after Table 73 change "...configured by a NVROM programming..." to "...configured by a NVRAM programming..." DELL comment number 121 Page=289 Subtype=Highlight Author=Kevin_Marks Comment= 7.9.1 Identification and hard reset sequence overview 8th Paragraph, 1st Sentence change "If a phy receives a HARD_RESET, it shall be considered a reset event and cause a hard reset (see 4.4.2) of the port containing that phy." to "If a phy receives a HARD_RESET following a phy reset sequence, it shall be considered a reset event and cause a hard reset (see 4.4.2) of the port containing that phy." DELL comment number 122 Page=291 Subtype=Highlight Author=Kevin_Marks Comment= 7.9.5.1 SL_IR state machines overview In Figure 136 - SL_IR (link layer identification and hard reset) state machines change bottom state machine title "IDENTIFY and HARD_RESET Control" to "Identification and hard reset control" to make it match text. DELL comment number 123 Page=291 Subtype=Highlight Author=Kevin_Marks Comment= 7.9.5.1 SL_IR state machines overview In Figure 136 - SL_IR (link layer identification and hard reset) state machines change bottom state machine state SL_IR_IRC1:Idle message Enable Disable SAS Link (Disable) send to "SL" to "SL or XL" to make it match text. DELL comment number 124 Page=295 Subtype=Highlight Author=Kevin_Marks Comment= 7.10 Power management The 1st Paragraph, 1st Sentence "SATA interface power management is not supported in SAS." seems to contradict section 6.8.5.1 SATA host emulation states overview, which states that SATA PM may be used on SAS initiators directly connect to SATA devices. From 6.8.5.1 "The power management states defined in this standard are for SAS initiator devices that support being attached to SATA devices; expander devices attached to SATA devices do not support power management in this standard." Add paragraph from 6.8.5.1 to 7.10. DELL comment number 125 Page=296 Subtype=Highlight Author=Kevin_Marks Comment= 7.11 SAS domain changes NOTE 30 - This occurs when the expander phy is reset or disabled with the SMP PHY CONTROL function DISABLE, LINK RESET, HARD RESET, or TRANSMIT SATA PORT SELECTION SIGNAL phy operations (see 10.4.3.10) as well as when dword synchronization is unexpectedly lost; Remove references to disable as transitions to SP0:OOB_COMINIT should not happen if the phy is disabled. BROADCAST (CHANGE) caused by disabling the phy in handled by b) in list with the next comment.. DELL comment number 126 Page=296 Subtype=Highlight Author=Kevin_Marks Comment= 7.11 SAS domain changes 3rd Paragraph b) in a,b,c list Change "b) after a virtual phy has been disabled with the SMP PHY CONTROL function DISABLE phy operation or internally begun reset with the LINK RESET or HARD RESET phy operations (see 10.4.3.10);" to "b) after a phy or virtual phy has been disabled with the SMP PHY CONTROL function DISABLE phy operation or virtual phy has internally begun reset with the LINK RESET or HARD RESET phy operations (see 10.4.3.10);" DELL comment number 127 Page=296 Subtype=Highlight Author=Kevin_Marks Comment= 7.11 SAS domain changes 1st Paragraph, 1st Sentence Change "After power on or receiving BROADCAST (CHANGE), an application client in each SAS..." to "After power on or receiving BROADCAST (CHANGE), the management application client in each SAS..." DELL comment number 128 Page=299 Subtype=StrikeOut Author=Kevin_Marks Comment= 7.12.3 Arbitration fairness Remove "NOTE 1" from NOTE 31. DELL comment number 129 Page=310 Subtype=Highlight Author=Kevin_Marks Comment= Figure 141 - SL (link layer for SAS phys) state machines (part 1) change state machine title from "Connection Control (part 1)" to "connection control (part 1)" to match text. DELL comment number 130 Page=311 Subtype=Highlight Author=Kevin_Marks Comment= Figure 142 - SL (link layer for SAS phys) state machines (part 2) change state machine name from "Connection Control " to "connection control (part 2)" to match text and figure 141.. DELL comment number 131 Page=311 Subtype=Highlight Author=Kevin_Marks Comment= Figure 142 - SL (link layer for SAS phys) state machines (part 2) change state machine name from "Receive OPEN Address Frame" to "receive OPEN address frame" to match text. DELL comment number 132 Page=311 Subtype=Highlight Author=Kevin_Marks Comment= Figure 142 - SL (link layer for SAS phys) state machines (part 2) In Receive OPEN Address Frame state machine, change "SL_RA1:RxOpen" to "SL_RA" as it is the only state as proposed in note on Figure 9. DELL comment number 133 Page=335 Subtype=Highlight Author=Kevin_Marks Comment= 7.16.5 Interlocked frames I question why the Interlock Frames section is in the link layer material, when the SSP link layer state machines do not seem to directly deal with "interlocked-ness" other than ACK/NAK balance issues. The Transport Layer would seem more appropriate for the material, since this is where it seems to enforce it along with the PL_OC. DELL comment number 134 Page=340 Subtype=Text Author=Kevin_Marks Comment= Figure 151 - SSP (link layer for SSP phys) state machines (part 1 - frame transmission) In figure 151, change state machine names to low case to match text. DELL comment number 135 Page=340 Subtype=Highlight Author=Kevin_Marks Comment= Figure 151 - SSP (link layer for SSP phys) state machines (part 1 - frame transmission) In Transmit Interlocked Frame Monitor Change "SSP_TIM:Tx_Interlock_Monitor" state name to "SSP_TIM" as it is a single state state machine as proposed in a note on Figure 9. DELL comment number 136 Page=340 Subtype=Highlight Author=Kevin_Marks Comment= Figure 151 - SSP (link layer for SSP phys) state machines (part 1 - frame transmission) In Transmit Frame Credit Monitor Change "SSP_TCM:Tx_Credit_Monitor" state name to "SSP_TCM" as it is a single state state machine as proposed in a note on Figure 9. DELL comment number 137 Page=340 Subtype=Highlight Author=Kevin_Marks Comment= Figure 151 - SSP (link layer for SSP phys) state machines (part 1 - frame transmission) In DONE Control Change "SSP_D:DONE_Wait" state name to "SSP_D" as it is a single state state machine as proposed in a note on Figure 9. DELL comment number 138 Page=341 Subtype=Highlight Author=Kevin_Marks Comment= Figure 152 - SSP (link layer for SSP phys) state machines (part 2 - frame reception) In Transmit ACK/NAK Control state machine Change "SSP_TAN:Tx_ACK/NAK Control" state name to "SSP_TAN" as it is a single state state machine as proposed in note on Figure 9. DELL comment number 139 Page=341 Subtype=Text Author=Kevin_Marks Comment= Figure 152 - SSP (link layer for SSP phys) state machines (part 2 - frame reception) In figure 152, change state machine names to low case to match text. DELL comment number 140 Page=341 Subtype=Highlight Author=Kevin_Marks Comment= Figure 152 - SSP (link layer for SSP phys) state machines (part 2 - frame reception) In Receive Frame Control Change "SSP_RF:Rcv_Frame" state name to "SSP_RF" as it is a single state state machine as proposed in note on Figure 9. DELL comment number 141 Page=341 Subtype=Highlight Author=Kevin_Marks Comment= Figure 152 - SSP (link layer for SSP phys) state machines (part 2 - frame reception) In Receive Frame Credit Monitor Change "SSP_RCM:Rcv_Credit_Monitor" state name to "SSP_RCM" as it is a single state state machine as proposed in note on Figure 9. DELL comment number 142 Page=341 Subtype=Highlight Author=Kevin_Marks Comment= Figure 152 - SSP (link layer for SSP phys) state machines (part 2 - frame reception) In Transmit Credit Control Change "SSP_TC:Tx_Credit_Control" state name to "SSP_TC" as it is a single state state machine as proposed in a note on Figure 9. DELL comment number 143 Page=341 Subtype=Highlight Author=Kevin_Marks Comment= Figure 152 - SSP (link layer for SSP phys) state machines (part 2 - frame reception) In Receive Interlocked Frame Monitor Change "SSP_RIM:Rcv_Interlock_Monitor" state name to "SSP_RIM" as it is a single state state machine as proposed in a note on Figure 9. DELL comment number 144 Page=344 Subtype=Highlight Author=Kevin_Marks Comment= 7.16.7.6.1 SSP_TF state machine overview Add "This state machine shall start in the SSP_TF1:Connected_Idle state." after the a,b,c list. DELL comment number 145 Page=347 Subtype=Highlight Author=Kevin_Marks Comment= 7.16.7.7 SSP_RF (receive frame control) state machine 5th paragraph b) list. change "SSP_TAN1:Idle state" to "SSP_TAN" to match state machine name in state diagram, and since it is a single state state machine. DELL comment number 146 Page=347 Subtype=Highlight Author=Kevin_Marks Comment= 7.16.7.7 SSP_RF (receive frame control) state machine 6th paragraph c) list. change "SSP_TAN1:Idle state" to "SSP_TAN" to match state machine name in state diagram, and since it is a single state state machine. DELL comment number 147 Page=347 Subtype=Highlight Author=Kevin_Marks Comment= 7.16.7.7 SSP_RF (receive frame control) state machine 7th paragraph, 1st sentence change "SSP_TAN1:Idle state" to "SSP_TAN" to match state machine name in state diagram, and since it is a single state state machine. DELL comment number 148 Page=347 Subtype=Highlight Author=Kevin_Marks Comment= 7.16.7.7 SSP_RF (receive frame control) state machine 7th paragraph c) list. change "SSP_TAN1:Idle state" to "SSP_TAN" to match state machine name in state diagram, and since it is a single state state machine. DELL comment number 149 Page=358 Subtype=Highlight Author=Kevin_Marks Comment= In Figure 158. Change "SMP_IP (link layer for SMP initiator ports) state machine" to "SMP_IP (link layer for SMP initiator phys) state machine" DELL comment number 150 Page=359 Subtype=Highlight Author=Kevin_Marks Comment= 7.18.4.4 SMP_TP (link layer for SMP target ports) state machine Change section heading to "7.18.4.4 SMP_TP (link layer for SMP target phys) state machine" DELL comment number 151 Page=360 Subtype=Highlight Author=Kevin_Marks Comment= In Figure 159 Change "SMP_TP (link layer for SMP target ports) state machine" to "SMP_TP (link layer for SMP target phys) state machine" DELL comment number 152 Page=360 Subtype=StrikeOut Author=Kevin_Marks Comment= 7.18.4.4.2.1 State description 3rd Paragraph, 1st Sentence remove "If this state receives an Invalid Dword Received message or an ERROR Received message after receiving an SOF Received message and before receiving an EOF Received message, then this state shall discard the Data Dword Received messages received before the subsequent SOF Received message." Sentence is incorrect, and case of INVALID DWORD or ERROR received is covered in the 5th paragraph. DELL comment number 153 Page=373 Subtype=Highlight Author=Kevin_Marks Comment= 8.2.2.3.8 Transition PL_OC2:Overall_Control to PL_OC1:Idle 1st Paragraph, 1st Sentence -a) in a,b list Change "a) sending a HARD_RESET Received confirmation to the link layer; or" to "a) sending a HARD_RESET Received confirmation to the transport layer; or" DELL comment number 154 Page=373 Subtype=Text Author=Kevin_Marks Comment= 8.2.3.1 PL_PM state machine overview Add Arbitration Wait Time Timer to Table 106 - PL_PM state machine timers, as this timer is created, initialized and set to the value received as an argument in Tx Open message in the PL_PM state machine. DELL comment number 155 Page=386 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.2.1 COMMAND information unit 2nd Paragraph,1st Sentence after Table 110 - Command information unit change "...that the SSP target port shall transfer first burst data..." to "...that the SSP initiator port shall transfer first burst data..." DELL comment number 156 Page=386 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.2.1 COMMAND information unit 2nd Paragraph,2st Sentence after Table 110 - Command information unit Change "...specifies that the SSP target port shall not transfer first burst data..." to "...specifies that the SSP initiator port shall not transfer first burst data..." DELL comment number 157 Page=388 Subtype=Text Author=Kevin_Marks Comment= 9.2.2.2 TASK information unit In Table 113 - TASK MANAGEMENT FUNCTION field Remove the "Uses LOGICAL UNIT NUMBER field" column in table. It provides no value, as they are all yes. DELL comment number 158 Page=389 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.2.3 XFER_RDY information unit 2nd Paragraph, 1st Sentence after Table 114 - XFER_RDY information unit change "If the ENABLE FIRST BURST field in the COMMAND frame (see 9.2.2.1) was set to one, then in the initial XFER_RDY frame for the command, the SSP target port shall set the REQUESTED OFFSET field to the value indicated by the FIRST BURST SIZE field in the Disconnect-Reconnect mode page (see 10.2.7.1.5)." to "f the ENABLE FIRST BURST field in the COMMAND frame (see 9.2.2.1) was set to one, then in the initial XFER_RDY frame for the command, the SSP target port shall set the REQUESTED OFFSET field to the value indicated by the FIRST BURST SIZE field (i.e., the amount of write data in 512-byte increments times the value in the FIRST BURST SIZE field) in the Disconnect-Reconnect mode page (see 10.2.7.1.5)." DELL comment number 159 Page=392 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.2.5.3 RESPONSE information unit RESPONSE_DATA format 2nd Paragraph, 1st Sentence Change "Table 118 defines the RESPONSE DATA field, which contains information describing protocol failures detected during processing of a request received by the SSP target port." to "Table 118 defines the RESPONSE DATA field, which contains information describing protocol failures detected during processing of a request received by the SSP target port or the completion status of a task management function. " DELL comment number 160 Page=396 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.4.1 SSP transport layer handling of link layer errors overview 2nd Paragraph, 1st Paragraph Change "...in the Protocol Specific Logical Unit..." to "...in the Protocol-Specific Logical Unit..." DELL comment number 161 Page=396 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.4.2 COMMAND frame - handling of link layer errors 6th Paragraph, 1st Sentence "An SSP initiator port should retransmit each COMMAND frame that does not receive an ACK at least one time." - seems to contradict the statements above in section 9.2.4.2, in that if the SSP initiator port receives a XFER_RDY, showing that the command was received, why would it re-send the command and cause an overlapped condition? A better statement may be "If the SSP initiator port does not receive an ACK, XFER_RDY frame or RESPONSE frame for a COMMAND frame sent, it should retry the COMMAND frame at least once." DELL comment number 162 Page=399 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.4.5.3 DATA frame without transport layer retries Last sentence Change "If an SSP initiator port transmits a write DATA frame and receives a NAK for that frame, the device server aborts the command (see 10.2.2)." to "If an SSP initiator port transmits a write DATA frame and receives a NAK for that frame, the application client aborts the command (see 10.2.2)." "Device server" contradicts 10.2.2, which says that SSP initiator port will abort the command with an ABORT TASK when a NAK is received. Unless the reference to 10.2.2 should be 10.2.3 (device server error handling), but this does not seem to make sense, because the write data could be for another command's XFER_RDY, so the device server does not know which command to abort and is discarded in the link layer The application client should abort the task with ABORT TASK. DELL comment number 163 Page=399 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.4.5.3 DATA frame without transport layer retries 2nd to last paragraph Change "2) the device server aborts the command (see 10.2.2)." to "2) the application client aborts the command (see 10.2.2)." Since it is Write Data, the ACK could have been lost forcing ACK/NAK Timeout. The application client should abort the command on the next connection, not the device, as it has no knowledge of the lost ACK. DELL comment number 164 Page=399 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.4.6 RESPONSE frame - handling of link layer errors 4th Paragraph, 2nd Sentence Change "If the ST_TFR state machine and the ST_TTS state machine not previously received the RESPONSE frame, they considers the RESPONSE frame to be the valid RESPONSE frame." to "If the ST_TFR state machine and the ST_TTS state machine have not previously received the RESPONSE frame, they shall consider the RESPONSE frame to be the valid RESPONSE frame." DELL comment number 165 Page=400 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.5.3 SSP target port error handling summary 4th Paragraph, end of sentence. Change "(see 10.2.1.3)." to "(see 10.2.1.4)" Seems more appropriate that this would reference Send Command Complete than SCSI Command Received, as Send Command Complete has the service response argument for reporting status. DELL comment number 166 Page=400 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.5.3 SSP target port error handling summary 5th Paragraph Change "If an SSP target port receives: a) a COMMAND frame with a tag that is already in use for a task management function; or b) a TASK frame with a tag that is already in used for a command or another task management function, the ST_TFR state machine may process this as an I_T nexus loss event (see 9.2.6.3.2)." to "If an SSP target port receives: a) a COMMAND frame with a tag that is already in use for a task management function; or b) a TASK frame with a tag that is already in used for a command or another task management function, the device server may return a RESPONSE frame with the DATAPRES field set to RESPONSE_DATA and the RESPONSE CODE field set to OVERLAPPED TAG ATTEMPTED (see ?????)." Depending on if the target port receives a) or b), the (see ?????) could be a) (see 10.2.1.4) b) (see 10.2.1.14) based on incorporation of 05-107r1. DELL comment number 167 Page=403 Subtype=Highlight Author=Kevin_Marks Comment= Figure 168 - ST_I (transport layer for SSP initiator ports) state machines In ST_IFR (initiator frame router) Change "ST_IFR:Initiator_Frame_Router" state name to "ST_IFR" as it is a single state state machine as proposed in a note on Figure 9. DELL comment number 168 Page=405 Subtype=StrikeOut Author=Kevin_Marks Comment= 9.2.6.2.2 ST_IFR (initiator frame router) state machine 14th Paragraph, 1st Sentence Remove "based on the content of the DATAPRES and RESPONSE DATA fields" Depending on whether the RESPONSE frame was for a command or task management function the RESPONSE DATA field may not exits (i.e. zero bytes). DELL comment number 169 Page=405 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.6.2.2 ST_IFR (initiator frame router) state machine 14th Paragraph, 1st Sentence "items" s/b "fields" DELL comment number 170 Page=405 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.6.2.2 ST_IFR (initiator frame router) state machine 15th Paragraph, 1st Sentence "items" s/b "fields" DELL comment number 171 Page=405 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.6.2.2 ST_IFR (initiator frame router) state machine 17th Paragraph, 1st Sentence "items" s/b "fields" DELL comment number 172 Page=407 Subtype=Text Author=Kevin_Marks Comment= 9.2.6.2.3.3.1 State description Used thru out ST_ITS and ST_TTS state machines: "...send a Transmit Frame (Interlocked) request to the port layer." Transmit Frame(Interlocked) request does not seem to be a request that is received or mentioned in the in the port layer. This would also applies to Transmit Frame (Non-interlocked) request used through out this clause. Understandably this would turn into TX Frame (Balanced Required) or Tx Frame (Balanced Not Required) request to the link layer. DELL comment number 173 Page=409 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.6.2.3.3.1 State description In Table 121 - Messages sent to the ST_IFR state machine based on port layer confirmations 1st Row, 1st Column Change "Transmission Status (ACK Received" to "Transmission Status (ACK Received)" DELL comment number 174 Page=412 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.6.2.3.5.2 Transition ST_ITS4:Prepare_Task to ST_ITS2:Initiator_Send_Frame Section header needs to be in Bold. DELL comment number 175 Page=415 Subtype=Highlight Author=Kevin_Marks Comment= Figure 169 - ST_T (transport layer for SSP target ports) state machines In ST_TFR (target frame router) Change "ST_TFR:Target_Frame_Router" state name to "ST_TFR" as it is a single state state machine as proposed in a note on Figure 9. DELL comment number 176 Page=417 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.6.3.2 ST_TFR (target frame router) state machine 14th Paragraph, 1st Sentence "items" s/b "fields" DELL comment number 177 Page=417 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.6.3.2 ST_TFR (target frame router) state machine 15th Paragraph, 1st Sentence "items" s/b "fields" DELL comment number 178 Page=417 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.6.3.2 ST_TFR (target frame router) state machine 20th Paragraph, 1st Sentence "items" s/b "fields" DELL comment number 179 Page=417 Subtype=Highlight Author=Kevin_Marks Comment= 9.2.6.3.2 ST_TFR (target frame router) state machine 16th Paragraph, 1st Sentence "items" s/b "fields" DELL comment number 180 Page=429 Subtype=Highlight Author=Kevin_Marks Comment= 9.4.1 SMP transport layer overview In Table 128 - SMP FRAME TYPE field Change "9.4.2" to "10.4.3.1" as 9.4.2 is proposed for removal below. DELL comment number 181 Page=429 Subtype=Highlight Author=Kevin_Marks Comment= 9.4.1 SMP transport layer overview In Table 128 - SMP FRAME TYPE field Change "9.4.3" to "10.4.3.2" as 9.4.3 is proposed for removal below. DELL comment number 182 Page=430 Subtype=StrikeOut Author=Kevin_Marks Comment= Remove Section 9.4.2 - SMP_REQUEST FRAME as it is redundant with 10.4.3.1 The removal of this section may cause a golbal change to SMP_REQUEST to SMP REQUEST. DELL comment number 183 Page=430 Subtype=StrikeOut Author=Kevin_Marks Comment= 9.4.2 SMP_REQUEST frame Remove Table 129, as it is redundant to Table 167. DELL comment number 184 Page=430 Subtype=StrikeOut Author=Kevin_Marks Comment= Remove Section 9.4.3 - SMP_RESPONSE frame as it is redundant with 10.4.3.2 and seems to have a slightly different format than 10.4.3.2. The removal of this section may cause a golbal change to SMP_RESPONSE to SMP RESPONSE. DELL comment number 185 Page=432 Subtype=Highlight Author=Kevin_Marks Comment= 9.4.5.2.2.1 State description Add text "This state is the initial state of the MT_IP state machine." DELL comment number 186 Page=432 Subtype=Highlight Author=Kevin_Marks Comment= 9.4.5.2.2.1 State description 1st Paragraph change "This state waits for a Send SMP Function Request request, which includes the following arguments: a) connection rate; b) destination SAS address; and c) request bytes." to "This state waits for a Send SMP Function Request request, which includes the following arguments: a) connection rate; b) destination SAS address; c) function; and d) additional request bytes." per proposed removal of SMP_REQUEST table 129. DELL comment number 187 Page=432 Subtype=Highlight Author=Kevin_Marks Comment= 9.4.5.2.2.2 Transition MT_IP1:Idle to MT_IP2:Send 1st Paragaph change "This transition shall occur after a Send SMP Function Request request is received. This transition shall include the following arguments: a) connection rate; b) destination SAS address; and c) request bytes." to "This transition shall occur after a Send SMP Function Request request is received. This transition shall include the following arguments: a) connection rate; b) destination SAS address; c) function; and d) additional request bytes." per proposed removal of SMP_REQUEST table 129. DELL comment number 188 Page=433 Subtype=Highlight Author=Kevin_Marks Comment= 9.4.5.2.3.1 State description 1st Paragraph Change "This state constructs an SMP_REQUEST frame using the following arguments received with the transition into this state: a) request bytes;" to "This state constructs an SMP_REQUEST frame using the following arguments received with the transition into this state: a) function; and b) additional request bytes;" per proposed removal of SMP_REQUEST table 129. DELL comment number 189 Page=434 Subtype=Highlight Author=Kevin_Marks Comment= 9.4.5.3.2.1 State description Add text "This state is the initial state of the MT_TP state machine." DELL comment number 190 Page=435 Subtype=Highlight Author=Kevin_Marks Comment= 9.4.5.3.3.1 State description 1st Paragraph Change "This state waits for a Send SMP Response request, which includes the following arguments: a) response bytes." to "This state waits for a Send SMP Response request, which includes the following arguments: a) function; b) function result; and c) response bytes." per proposed removal of SMP_RESPONSE table 130. DELL comment number 191 Page=437 Subtype=Highlight Author=Kevin_Marks Comment= Table 132 - SCSI architecture mapping Remove table note b and references.. "b SCSI initiator port Data Transfer transport protocol services are not specified by SAM-3." SAM-3 does contain the Terminate Data Transfer protocol service and Data-In and Data-Out Delivery Service. DELL comment number 192 Page=438 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.1.3 SCSI Command Received transport protocol service "SCSI Command Received (IN (I_T_L_Q Nexus, CDB, Task Attribute, [Task Priority], [Command Reference Number]))" SCSI Command Received is missing First Burst Enabled argument. DELL comment number 193 Page=442 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.1.7 Data-In Delivered transport protocol service "Data-In Delivered (IN (I_T_L_Q Nexus))" Add Delivery Results argument as defined in Table 138. DELL comment number 194 Page=443 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.1.9 Data-Out Received transport protocol service Data-Out Received (IN (I_T_L_Q Nexus)) Add Delivery Results argument as defined in Table 140.. DELL comment number 195 Page=443 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.1.10 Terminate Data Transfer transport protocol service In Table 141 - Receive Data-Out transport protocol service arguments SAS SSP implementation of the Nexus Change "I_T nexus, I_T_L nexus, or I_T_L_Q nexus, specifying the scope of the data transfer(s) to terminate." to "I_T_L nexus, or I_T_L_Q nexus, specifying the scope of the data transfer(s) to terminate." The statement above the table says "The device server uses the Terminate Data Transfer ...." The device server of one LU should not be able to affect/terminate data transfers to other LU. DELL comment number 196 Page=444 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.1.11 Data Transfer Terminated transport protocol service In Table 142 - Data-Out Received transport protocol service arguments SAS SSP implementation of the Nexus argument. Change "I_T nexus, I_T_L nexus, or I_T_L_Q nexus indicated by the preceding Terminate Data Transfer () call." to "I_T_L nexus, or I_T_L_Q nexus indicated by the preceding Terminate Data Transfer () call." per previous comment, because I_T nexus should not be allowed as a argument, I_T Nexus should not be allowed as a returned indication. DELL comment number 197 Page=447 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.2 Application client error handling 1st sentence "delivers" s/b "returns" DELL comment number 198 Page=448 Subtype=StrikeOut Author=Kevin_Marks Comment= 10.2.3 Device server error handling 1st Paragraph, 1st Sentence Remove "management functions" from "...device server(s) shall abort all task management functions received on that I_T nexus..." DELL comment number 199 Page=448 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.3 Device server error handling 2nd Paragraph, 1st Sentence Should Receive Data-Out () be Data-Out Received ()? DELL comment number 200 Page=448 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.4 Task router and task manager error handling 1st Paragraph c) in second a,b,c list Change "c) call Task Management Function Executed () with the Service Response set to FUNCTION REJECTED - Overlapped Tag Attempted (i.e., requesting that the target port set the DATAPRES field to RESPONSE_DATA and the RESPONSE CODE field to OVERLAPPED TAG ATTEMPTED)." to " c) call Send Command Complete () with a with the Service Response set to SERVICE DELIVERY OR TARGET FAILURE (i.e., requestingthat the target port set the DATAPRES field to RESPONSE_DATA and the RESPONSE CODE field to OVERLAPPED TAG ATTEMPTED) if the SCSI command received caused the overlapped tag condition; or call Task Management Function Executed () with the Service Response set to FUNCTION REJECTED - Overlapped Tag Attempted (i.e., requesting that the target port set the DATAPRES field to RESPONSE_DATA and the RESPONSE CODE field to OVERLAPPED TAG ATTEMPTED) if the SCSI task management function received caused the overlapped tag condition" Seems that if it was a command that was received last, that cause the overlapped tag condition, that the response would be for that command, and not the task management function that was already in the task set. DELL comment number 201 Page=448 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.4 Task router and task manager error handling 1st Paragraph, b) in first a,b list Remove extra "calls" in sentence. "b) an SSP target port calls calls Task Management Request Received () with a tag already in use by a SCSI command or SCSI task management function in any logical unit," DELL comment number 202 Page=450 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.7.1.1 Disconnect-Reconnect mode page overview 3rd Paragraph, 1st Sentence "ILLEGAL FIELD IN PARAMETER LIST." Should this be "INVALID FIELD IN PARAMETER LIST", else it does not have a assigned ASC/ASCQ in SPC-3. It is also incorrect in SPC-3 for Disconnect-Reconnect mode page. DELL comment number 203 Page=453 Subtype=Text Author=Kevin_Marks Comment= 10.2.7.2.1 Protocol-Specific Port mode page overview On I_T NEXUS LOSS TIME Add note or text that the SSP initiator port should also use the I_T NEXUS LOSS TIME value in the Protocol-specific port mode page for reporting I_T nexus loss for that SSP target port. DELL comment number 204 Page=455 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.7.2.3 Protocol-Specific Port mode page - Phy Control And Discover subpage In Table 154 - SAS phy mode descriptor Change Byte 2 to "Reserved" from "Restricted (for SMP PHY CONTROL function's PHY OPERATION field)" DELL comment number 205 Page=460 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.9.1 Protocol-Specific diagnostic page 2rd Paragraph, 1st Sentence "ILLEGAL FIELD IN PARAMETER LIST." Should this be "INVALID FIELD IN PARAMETER LIST", else it does not have a assigned ASC/ASCQ in SPC-3. DELL comment number 206 Page=467 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.11 SCSI vital product data (VPD) In Table 165 - Device Identification VPD page required identification descriptors Association row Change "ASSOCIATION 1h (i.e., SCSI target port) 1h (i.e., SCSI target port)" to "ASSOCIATION 01b (i.e., SCSI target port) 01b (i.e., SCSI target port)" DELL comment number 207 Page=467 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.11 SCSI vital product data (VPD) In Table 165 - Device Identification VPD page required identification descriptors Code Set row Change "1b (i.e., binary)" to "1h (i.e., binary)" DELL comment number 208 Page=468 Subtype=Highlight Author=Kevin_Marks Comment= 10.2.11 SCSI vital product data (VPD) 2nd Paragraph after Table 165 - Device Identification VPD page required identification descriptors "Logical units may include additional identification descriptors than those required by this standard (e.g., SCSI target devices with SCSI target ports using other SCSI transport protocols may return additional target device names for those other SCSI transport protocols)." Sentence seems to be an artifact from SAS-1, when the SCSI device name was required. Propose removing everything following with the e.g.. DELL comment number 209 Page=474 Subtype=StrikeOut Author=Kevin_Marks Comment= 10.4.3.2 SMP function response frame format In Table 170 - FUNCTION RESULT field (part 2 of 2) - Code value 16h (PHY VACANT) - Description Remove "The phy specified by the PHY IDENTIFIER field in the SMP request frame does not exist or" This statement is the same as Code value 10h (PHY DOES NOT EXIST). Do not agree that return 10h and 16h are the same. DELL comment number 210 Page=477 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.3 REPORT GENERAL function 9th Paragraph, 2nd Sentence after Table 172 - REPORT GENERAL response Add sentence "Devices other than expander devices shall not support this bit" before "Changes in this bit from one to zero result in a BROADCAST (CHANGE) being originated." DELL comment number 211 Page=477 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.3 REPORT GENERAL function 10th Paragraph, 2nd Sentence after Table 172 - REPORT GENERAL response Add sentence "Devices other than expander devices shall not support this bit" after "An expander device without a configurable route table shall have the CONFIGURABLE ROUTE TABLE bit set to zero." DELL comment number 212 Page=478 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.4 REPORT MANUFACTURER INFORMATION function In Table 174 - REPORT MANUFACTURER INFORMATION response - Byte 8 Make 1.1 in SAS-1.1 FORMAT, SMALL CAPS, as it is part of the field name and not the value of the field.. DELL comment number 213 Page=479 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.4 REPORT MANUFACTURER INFORMATION function 4th Paragraph, 1st and 2nd Sentences after In Table 174 - REPORT MANUFACTURER INFORMATION response "A SAS-1.1 FORMAT bit set to..." Make 1.1 in SAS-1.1 FORMAT, SMALL CAPS, as it is part of the field name. DELL comment number 214 Page=483 Subtype=StrikeOut Author=Kevin_Marks Comment= 10.4.3.5 DISCOVER function In Table 178 - NEGOTIATED PHYSICAL LINK RATE field, 1st Sentence -Code Value 2h Remove "(either SAS or SATA)" SATA does not do fall back test (final negotiation window.) DELL comment number 215 Page=483 Subtype=StrikeOut Author=Kevin_Marks Comment= 10.4.3.5 DISCOVER function In Table 178 - NEGOTIATED PHYSICAL LINK RATE field, 4st Sentence - Code Value 4h Remove "2h," Per comment above on 2h code value, SATA phy should not end up in code 2h, as it does not support fall back test or change i.e. in 2h description to e.g. DELL comment number 216 Page=485 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.5 DISCOVER function 11th Paragraph after Table 179 - ATTACHED SATA PORT SELECTOR and ATTACHED SATA DEVICE bits Change "The ATTACHED SAS ADDRESS field shall be updated: a) after the identification sequence completes, if a SAS device or expander device is attached; or b) at SATA spinup hold time (see 6.10), if a SATA device is attached." to "The ATTACHED SAS ADDRESS field shall be updated: a) after the identification sequence completes, if a SAS device or expander device isattached; or b) at SATA spinup hold time (i.e. COMSAS detect timeout expires), if a SATA device is attached." A phy (STP bridge) may not support SATA spinup hold, so the COMSAS detect timeout expires clarifies the time. DELL comment number 217 Page=486 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.6 REPORT PHY ERROR LOG function 1st Paragraph,1st Sentence Change "This SMP function may implemented by any SMP target port." to "This SMP function may be implemented by any SMP target port. DELL comment number 218 Page=488 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.6 REPORT PHY ERROR LOG function 5th Paragraph after Table 184 - REPORT PHY ERROR LOG response Change "The INVALID DWORD COUNT field indicates the number of invalid dwords (see 3.1.98) that have been received outside of phy reset sequences (i.e., between when the SP_DWS state machine (see 6.9) sends a Phy Layer Ready (SAS) confirmation and when it sends a Phy Layer Not Ready confirmation to the link layer). The count shall stop at the maximum value." to "The INVALID DWORD COUNT field indicates the number of invalid dwords (see 3.1.98) that have been received outside of phy reset sequences (i.e., between when the SP state machine (see 6.8) sends a Phy Layer Ready (SAS) confirmation and when it sends a Phy Layer Not Ready confirmation to the link layer). The count shall stop at the maximum value." Do these counters not apply to SATA? If so, need to add or Phy Layer Ready (SATA) confirmation. DELL comment number 219 Page=489 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.6 REPORT PHY ERROR LOG function 6th Paragraph after Table 184 - REPORT PHY ERROR LOG response "The LOSS OF DWORD SYNCHRONIZATION COUNT field indicates the number of times the phy has lost dword synchronization and restarted the link reset sequence (see 6.8) of phy reset sequences. The count shall stop at the maximum value." Is the LOS SYNC COUNT only incremented if a the link reset sequence happens? Several SP states allow for a Start DWS message to prevent a link reset sequence, such as SP15:SAS_PHY_Ready. If this LOS is defined as DWS Loss, then remove "and restarted the link reset sequence (see 6.8) of phy reset sequences." DELL comment number 220 Page=491 Subtype=Highlight Author=Kevin_Marks Comment= 8th Paragraph after Table 186 - REPORT PHY SATA response Change "...link reset sequence (see ATA/ATAPI-7 V3 and SATA2-EXT)." to "...link reset sequence (see ATA/ATAPI-7 V3 and SATAII-EXT)." DELL comment number 221 Page=496 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.10 PHY CONTROL function 1st Paragraph, 2nd Sentence Change "This SMP function may implemented by any SMP target port." to "This SMP function may be implemented by any SMP target port." DELL comment number 222 Page=498 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.10 PHY CONTROL function In Table 192 - PHY OPERATION field (part 1 of 2) Code value 01h (LINK RESET) Row Change 2nd Paragraph, 2nd Sentence in description column "The phy shall bypass the SATA spinup hold state." to "The phy shall bypass the SATA spinup hold state, if attached to a SATA device." DELL comment number 223 Page=500 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.11 PHY TEST FUNCTION function 1st Paragraph, 2nd Sentence Change "This SMP function may implemented by any SMP target port." to "This SMP function may be implemented by any SMP target port." DELL comment number 224 Page=502 Subtype=Highlight Author=Kevin_Marks Comment= 10.4.3.11 PHY TEST FUNCTION function In Table 196 - PHY TEST FUNCTION field Code value 01h - Description column- 1st Sentence Change "MAXIMUM PHYSICAL LINK RATE" to "PHY TEST PATTERN PHYSICAL LINK RATE" DELL comment number 225 Page=504 Subtype=Highlight Author=Kevin_Marks Comment= A.1 Jitter tolerance pattern (JTPAT) Change blue text to black in Table A.1 „ JTPAT for RD+. DELL comment number 226 Page=505 Subtype=Highlight Author=Kevin_Marks Comment= A.1 Jitter tolerance pattern (JTPAT) Change blue text to black in Table A.2 „ JTPAT for RD DELL comment number 227 Page=541 Subtype=Highlight Author=Kevin_Marks Comment= G.1 STP differences from Serial ATA (SATA) change "...device using an active/standby mode called affiliations..." to "...device using a reserve/release style mechanism called affiliations..." Active/standby seems more like a Port selector or failover mechanism. DELL comment number 228 Page=541 Subtype=Highlight Author=Kevin_Marks Comment= G.2 STP differences from Serial ATA II Remove "c) staggered device spinup;" SATA Spinup Hold seems and phy reset are methods to control staggered spinup. DELL comment number 229 Page=542 Subtype=Highlight Author=Kevin_Marks Comment= G.4 SATA port selector considerations 1st paragraph,1st sentence change "...SATA port selector (see SATA2-PS) in a SAS..." to "...SATA port selector (see SATAII-PS) in a SAS..." DELL comment number 230 Page=574 Subtype=Text Author=Kevin_Marks Comment= L.1 Discover process example implementation overview Through out comments in source code, "will" and "must" are used. Although an informative annex, recommend changing instances of "will" and "must" to "should"/"shall". ************************************************************** Comments attached to No ballot from Robert H. Nixon of Emulex: PDF page numbers are used (i.e., a single number sequence for the whole document) Emulex concurs with the following issue identified by Intel: Page: 124; Author: rlsheffi; Comment: There is no place in the standard that specifies when (if ever) the ATTACHED SAS ADDRESS is set to zero. Page 231, 6.8.3.3.2 para 2 line 3 COMWAKE_Recieved s/b COMWAKE_Received Emulex concurs with the following issue identified by Intel: Page: 296; Author: rlsheffi; Comment: 7.9.5.5.3 SL_IR_IRC2:Wait state 7.9.5.5.3.1 State description There is a problem that there is currently no definition for how a phy associated with an STP/SATA bridge becomes enabled. ************************************************************** Comments attached to No ballot from Rob Elliott of Hewlett Packard Co.: HPQ comment number 1 Page=95 Subtype=Text Author=relliott Comment= 4.2.6 Port identifiers Comment received from Doug Gilbert (linux): Section 4.2.6 on Port identifiers says: "Each SAS initiator port, target port and target/initiator port shall include a SAS address (see 4.2.2) as its port identifier. The selected SAS address shall be used for no other name or identifier." Current HBAs (4 or 8 phy) can have multiple initiator ports in different SAS domains each with the same SAS port identifier. IMO that doesn't sit well with the second sentence fromdraft shown above (namely the unqualified "... or identifier" part. Or perhaps I am misunderstanding what a SAS HBA should publish as its port identifier for its second and subsequent ports? My reply: Good point. The initiator device certainly is allowed to use that port identifier in another domain (causing another port to be created). It's trying to ensure that the identifier is not used as (for targets or initiators) a device name or (for targets) a logical unit name. HPQ comment number 2 Page=108 Subtype=Text Author=relliott Comment= 4.4.2 Hard reset Clarify what "hard reset" means or does not mean in an expander. This still causes confusion. HPQ comment number 3 Page=154 Subtype=Text Author=relliott Comment= 5.2.3.4.7 SAS internal compact wide connector pin assignments Table 29 - Backplane pinout The A to Rx, B to Tx mapping does not match figure 76, which shows A's carrying the Rx lines and B's carrying the Tx lines. This table is probably incorrect. HPQ comment number 4 Page=161 Subtype=Text Author=relliott Comment= 5.2.4.3.2 SAS internal wide symmetric cables Figure 76 - controller to backplane cable On the right side (backplane pinout), the A to Rx, B to Tx mapping does not match table 29, which has A's carrying the Tx lines and B's carrying the Rx lines. This figure is probably correct. HPQ comment number 5 Page=161 Subtype=Text Author=relliott Comment= 5.2.4.3.2 SAS internal wide symmetric cables Figure 76 - controller to backplane cable This figure is identical to the following figure 77 (controller to controller), except the "backplane" vs "connector" label on the right. If that is truly the case, then there should not be a special "backplane" pinout. (it's possible that the SIDEBAND signal names are different - if so, then they are indeed different) HPQ comment number 6 Page=161 Subtype=Text Author=relliott Comment= 5.2.4.3.2 SAS internal wide symmetric cables Figure 76 - controller to backplane cable The left side (controller) has SIDEBAND0 on A8, while table 29 has it on B8. HPQ comment number 7 Page=164 Subtype=Text Author=relliott Comment= 5.2.3.4.2 SAS internal wide symmetric cables (general comment on all cable figures) The depiction of the grounds is misleading in these cable figures. Show grounds going into a cylinder with dotted lines. Show paddle boards for the crossovers of the signals where needed rather than just crossing the lines in space. Alternatively, just show the grounds going into circles at each end (not full cylinders) labeled "twinaxial dual drain shield" and don't show them connected from one side to theother. HPQ comment number 8 Page=170 Subtype=Highlight Author=relliott Comment= 5.2.6 Impedance and media specifications Table 31 external cables The specification of: Maximum intra-pair skew (h, k): 20 ps is barely achievable by commodity cables and may not be that important (it causes the corners of the eye diagram to become rounded off). See 05-098. Either raise the number or eliminate it. HPQ comment number 9 Page=171 Subtype=Highlight Author=relliott Comment= 5.2.6 Impedance and media specifications Table 32 - internal wide cables The number: Maximum intra-pair skew: 10 ps may not be needed (see comment on table 31 for external cables). If this row remains, then footnotes h and k from table 31 which describe the measurement techniques should be copied here. HPQ comment number 10 Page=190 Subtype=Text Author=relliott Comment= 5.3.6.4 Receiver device jitter tolerance eye mask In January phy WG, was asked to add precalculated Z1tol values somewhere. Need specifics on what to do. HPQ comment number 11 Page=193 Subtype=Text Author=relliott Comment= 5.3.7.5 Transmitter device signal output levels for OOB signals The toggling algorithm is bogus and should not be used if SATA device attachment is supported. It leads to overdriving signals into the SATA device, which might have a 600 - 700 mV maximum expectation. Instead, a SAS phy supporting SATA device attachment needs to always use SATA compatible levels for COMINIT, only switching to SAS levels if it receives a COMSAS. A SAS receiver (if a SAS drive is attached) should have no problem receiving the lower levels - no more of a problem than a SATA device in that same position. If it cannot work with lower levels, then a SATA device would not be able to work either and it's not really an attachment point that supports SATA device attachment. SAS phys not concerned with SATA device attachment (e.g. phys attached to external cable connectors) need to use their normal SAS levels. Proposals discussing this topic include 05-019 and 05-077. HPQ comment number 12 Page=229 Subtype=Highlight Author=relliott Comment= 6.8.3.2.1 SP0:OOB_COMINIT state description "SMP Reset request" is not defined anywhere. HPQ comment number 13 Page=237 Subtype=Text Author=relliott Comment= 6.8.4.9 SP15:SAS_PHY_Ready and 6.8.5.8 SP22:SATA_PHY_Ready need to clarify how COMINIT Detected works in SP15 and SP22 (and maybe other states). If the differential voltage level drops below 120 mV multiple times meeting COMINIT timing, is that enough? Or is the voltage drop ignored until dword sync is declared lost by SP_DWS? DWS Reset Timeout is 1 ms; COMINIT idle time is 525 ns. So, COMINIT Detected will be seen before DWS is declared lost. HPQ comment number 14 Page=239 Subtype=Highlight Author=relliott Comment= 6.8.5.4.2 Transition SP18 to SP0 "Transition SP187" s/b "Transition SP18" HPQ comment number 15 Page=243 Subtype=StrikeOut Author=relliott Comment= 6.8.7.2 Transition SP26 to SP0 Delete "upon entry to SP0:OOB_COMINIT." HPQ comment number 16 Page=243 Subtype=Text Author=relliott Comment= 6.9.1 SP_DWS state machine When SP_DWS declares DWS Lost but not DWS Reset, that could be interpreted as "loss of dword sync" which is a reason an expander would forward BREAK. The intent was that only happens if there is loss of dword sync resulting in the OOB sequence restarting. Clarify throughout. HPQ comment number 17 Page=270 Subtype=Text Author=relliott Comment= 7.2.5.1 OPEN_REJECT For SAS phys (not expander phys), consider dropping the priority list in favor of the 1)2)3) list in the SL_CC:Selected state, the only one that uses it. For expander phys, the decision is not made by XL (in XL4:Open_Reject), it's made by the ECM (choosing which Arb Reject to send). I don't know if there's a better place for the list than its current location since we don't define ECM state machines. There are two candidates: a) 4.6.6.3 defines the Arb Rejects. b) 7.12.4.1 has the arbitration rules, but does not have an ordered list right now enforcing the priority. HPQ comment number 18 Page=299 Subtype=Text Author=relliott Comment= 7.12.3 Arbitration fairness should point to port layer section dealing with AWT stopping here. don't want to imply that this "should not" rule overrides the port layer normal stopping of AWT when it has no more frames to send. HPQ comment number 19 Page=325 Subtype=Text Author=relliott Comment= 7.15.3 XL0:Idle state Comment from Expert I/O (in 05-141r0): Expander - Backoff Reverse Path Problem Expander Port 0 forwards an open to Expander Port 1, which causes Expander Port 0 to transition to XL3:Open_Confirm_Wait. Expander Port 1 receives an open address frame from the device it is connected. The received open address frame wins according to arbitration rules and thus causes Expander Port 1 to issue a Backoff Reverse Path message destined to Expander Port 0. The specification indicates that upon reception of the backoff reverse path message, Expander Port 0 should transition to XL5:Forward_Open. The specification goes on to say upon entry into XL5:Forward_Open, the expander port should transmit an open address frame based on the arguments of the oaf coincident with the state transition. However, in the case of the backoff reverse path message, there is no mechanism detailed to provide the Expander Port with the open address frame arguments along with the message. Solution This problem could be solved by having the expander port that received the backoff reverse path message transition to XL0:Idle rather than XL5:Forward Open. This will enable the expander port to be ready to accept the forward open message that will follow the backoff reverse path message and proceed as described in the specification. Alternatively, the backoff reverse path message could include the arguments for the open address frame along with the message. However, this option seems more intrusive than the first option HPQ comment number 20 Page=326 Subtype=Text Author=relliott Comment= 7.15.4 XL1:Request_Path state Comment from Expert I/O in 05-141r0: Expander - Request Path Handling Problem The specification should clarify what should occur in the following condition: Expander Port 1 issues a request path message which will route to Expander Port 0 resources. Expander Port 1 wins arbitration and proceeds to issue a forward open message that will go to Expander Port 0. Coincidentally (or any time up to receiving the forward open message from Expander Port 1), an open address frame is received by Expander Port 0. This causes Expander Port 0 to transition to XL1:Request_Path. While Expander Port 0 is in XL1:Request_Path the forward open message is received. It is not clear what the expander link should do from this point forward. If the open address frame received by Expander Port 0 is greater, ultimately a backoff retry or backoff reverse path message should be issued to Expander Port 1. If the open address frame received by the forward open message is greater, the requestpath message to the ECM should be negated. Neither of these methods is explained. Solution A possible solution requires modification in both the XL1:Request_Path section of the specification and the request path handling in the ECM. In the XL1:Request_Path section, the contents of the received open address frame could be kept. Upon receiving a forward open message while in XL1:Request_Path, the expander link uses arbitration rules to determine if a backoff retry message or backoff reverse path message should be issued while remaining in the same state. If either of these messages is issued, then no further modifications are necessary since the request path message from Expander Port 0 will control the state operation of Expander Port 0. If the forward open message wins arbitration over the received open address frame by Expander Port 0, the state transition to XL5:Forward_Open would take place as described. The only modification in this case would be that the ECM would ignore the request path messagealready issued by Expander Port 0. As a note, the cases are covered if the open address frame is received while Expander Port 0 is in XL5:Forward_Open and XL6:Open_Confirm_Wait. The only case missing in the specification is the case described HPQ comment number 21 Page=337 Subtype=Text Author=relliott Comment= 7.16.6 Closing an SSP connection Point to 7.12.8 (Breaking a connection) somewhere in 7.16, since some SSP specific rules are hidden there HPQ comment number 22 Page=340 Subtype=Text Author=relliott Comment= 7.16.7.1 SSP state machines Figure 151 - SSP part 1 Request Close and Request Break also go to all the other SSP state machines (in other figures), which is not mentioned in the figure. In this figure, it is shown as an input on the right, but not shown coming from SSP_D state which is also on this page. HPQ comment number 23 Page=352 Subtype=Text Author=relliott Comment= 7.17.4 Affiliations What happens when clear affiliation attempted while a connection open? vendor specific choice of: reject, accept and do it at the end of the connection, accept but do nothing HPQ comment number 24 Page=366 Subtype=Text Author=relliott Comment= 8.2.2.2 PL_OC1:Idle state Should be clarified that the pools of requests exist even while OC is in OC1. Going from OC2 to OC1 doesn't empty them. It's debatable whether new requests should be accepted while in OC1. The port might just be momentarily offline while its phy(s) are performing a link reset sequence. HPQ comment number 25 Page=366 Subtype=Text Author=relliott Comment= 8.2.2.2 PL_OC1:Idle The I_T Nexus Loss timer should continue to run after OC has moved into OC1 because all its phys become disabled. If they are disabled for too long while the OC has any useful work for them to do, it should be treated as an I_T nexus loss. This makes it work the same as if a remote physical link went down and connections requiring that physical link start returning OPEN REJECT (NO DESTINATION). HPQ comment number 26 Page=378 Subtype=Text Author=relliott Comment= 9.2.3.4 PL_PM3 Connected state Comment from Expert I/O in 05-141r0: Port Layer - Frame Transmitted Handshake Problem Due to the architectural freedom of having multiple SSP Transports running concurrently on top of a single Port Layer, multiple frames with different tags may be queued to the port layer. The port layer section of the specification does not describe any restriction for issuing multiple transmit frame messages to the link layer as long as the protocol, connection rate, and destination address match. However, the SSP Link Layer state machine is specified such that it can only accept one transmit frame message at a time. This creates an environment where a frame could be implicitly dropped if the transmit frame message is issued by the Port Layer while the SSP Link Layer is not in a state that recognizes the message. Solution The description of a handshake should be added to the Port Layer section of the specification. Specifically in the PL_PM3:Connected state should specify that a new transmit frame message can only be issued if there are no outstanding frame transmitted confirmations from the SSP Link Layer. HPQ comment number 27 Page=395 Subtype=Text Author=relliott Comment= 9.2.3 Sequences of SSP frames Should explicitly state that, for the same command, the target port may send DATA frames for the read direction at the same time it is receiving DATA frames for the write direction. The ST_I and ST_T state machines might not be able to do that as written. HPQ comment number 28 Page=396 Subtype=Text Author=relliott Comment= 9.2.4.2 COMMAND frame link layer errors Missing "(see 9.4.3.x)" references in most of these paragraphs HPQ comment number 29 Page=396 Subtype=Text Author=relliott Comment= 9.2.4.2 COMMAND frame link layer errors May be missing a DATA paragraph (per 9.2.6.3.3.2.6) HPQ comment number 30 Page=396 Subtype=Highlight Author=relliott Comment= 9.2.4.2 COMMAND frame link layer errors After "ACK" add "or RESPONSE, XFER_RDY, or DATA frame" to comprehend all the implicit ACK conditions just discussed. May be best to reword altogether. The purpose of this kind of rule should be to guide the OS drivers not to give up after just one error. 10.2.2 has all the rules with more detail. HPQ comment number 31 Page=399 Subtype=Highlight Author=relliott Comment= 9.2.5.2 SSP initiator port error handling summary Change "error handling" to "transport layer error handling" HPQ comment number 32 Page=400 Subtype=Highlight Author=relliott Comment= 9.2.5.2 SSP initiator port [transport layer] error handling summary Explain "data offset that was not expected" in more detail. DATA OFFSET field not sequential in the normal case, or not earlier that the current value if CHANGING DATA POINTERS is set to 1. HPQ comment number 33 Page=400 Subtype=Highlight Author=relliott Comment= 9.2.5.3 SSP target port error handling summary Change "error handling" to "transport layer error handling" HPQ comment number 34 Page=400 Subtype=Text Author=relliott Comment= 9.2.5.2 SSP initiator port error handling summary More reason that "data offset that was not expected" needs to be more specific. Comment from Rich Deglin, Vitesse: Initiator Target <=== DATA frame <=== DATA frame w/CRC error <=== DATA frame CHANGING DATA POINTERS=0 ... ACK ===> NAK ===> ACK ===> ... <=== DATA frame CHANGING DATA POINTERS=1 Due to the non-interlocked nature of data transfer, the target may have continued to transmit DATA frames for some time before it discovers that one of them was NAK'ed. Meanwhile the initiator has seen an "unexpected" data offset, but CHANGING DATA POINTERS=0. I believe the initiator is compelled to abort the command at this point. HPQ comment number 35 Page=401 Subtype=Highlight Author=relliott Comment= 9.2.5.3 SSP target port [transport layer] error handling summary Explain "data offset that was not expected" in more detail. DATA OFFSET field not sequential in the normal case, or not earlier if CHANGING DATA POINTERS is set to 1. HPQ comment number 36 Page=402 Subtype=Text Author=relliott Comment= 9.2.6.2.1 ST_I state machines Comment from ExpertIO in 05-141r0: SSP Transport Layer - Ack Transmitted Confirmation Needs Tag Argument Problem When an ack transmitted confirmation is received by the SSP Transport layer, it is not known for which frame the ack transmitted confirmation is associated. For instance, in the case of a wide link where a single transport layer is servicing commands for multiple tags simultaneously, the ST layer needs to know which ack transmitted confirmation is associated with which received frame. Solution The port layer has access to the information regarding which tag is associated with which confirmation. The specification should detail that the transmission status and the ack transmitted message should include an argument of the tag associated with the confirmation. HPQ comment number 37 Page=410 Subtype=Highlight Author=relliott Comment= 9.2.6.2.3.2.1 ST_ITS2:Initiator_Send_Frame Explain "requested offset is not expected" HPQ comment number 38 Page=411 Subtype=Text Author=relliott Comment= 9.2.6.2.3.3.6 ST_ITS2 to ST_ITS6 Note 53 is not reflected in 9.2.4.2 the error summary. The note says that read DATA frames are honored even though the COMMAND has not been ACKed. add para to 9.2.4.2 for read DATA frames that points here HPQ comment number 39 Page=412 Subtype=Highlight Author=relliott Comment= 9.2.6.2.3.7.1 ST_ITS6:Receive_Data_In Expand explanation of "not expected" HPQ comment number 40 Page=412 Subtype=Text Author=relliott Comment= 9.2.6.2.3.6 ST_ITS5:Prepare_Data_Out Comment from Expert I/O in 05-141r0: SSP Transport Layer - Balance Counter Problem The specification is very detailed in the description of the ITS state transitions. A section particularly describes how the ITS cannot transition out of PREPARE_DATA_OUT until it has received as many ack received confirmations as data frames it has sent out. This wording implies a counter that is not explained. Solution The specification should describe a balance counter (similar to ones described in the Link Layer) that increments on every frame transmitted transmission status confirmation and decrements on every ack received transmission status confirmation HPQ comment number 41 Page=426 Subtype=Highlight Author=relliott Comment= 9.2.6.3.3.6.1 ST_TTS5:Receive_Data_Out Regarding: "data offset was not expected (i.e., the CHANGING DATA POINTER bit is set to one and the value in the DATA OFFSET field is not set to the data offset associated with the XFER_RDY frame, or the CHANGING DATA POINTER bit is set to zero and the value in the DATA OFFSET field is not set to the value in the DATA OFFSET FIELD in the previous write DATA information unit plus the number of bytes in that information unit)" The i.e. list in 1) is incomplete. If an initiator violates the NUMBER OF FILL BYTES rules, it could send a DATA OFFSET that is a) not a multiple of 4 - violating the alignment rule; or b) is a multiple of 4 - leaving a gap and violating another rule. Change to e.g. and discuss the alignment rule too. HPQ comment number 42 Page=477 Subtype=Highlight Author=relliott Comment= 10.4.3.3 REPORT GENERAL function After "virtual phys" add "and any vacant phys" HPQ comment number 43 Page=478 Subtype=Highlight Author=relliott Comment= 10.4.3.4 REPORT MANUFACTURER INFORMATION Table 174 10.4.3.5 DISCOVER Table 175 and 176 10.4.3.6 REPORT PHY ERROR LOG Table 183 and 184 10.4.3.7 REPORT PHY SATA Table 185 and 186 10.4.3.8 REPORT ROUTE INFORMATION Table 187 and 188 10.4.3.9 CONFIGURE ROUTE INFORMATION Table 189 10.4.3.10 PHY CONTROL Table 191 10.4.3.11 PHY TEST FUNCTION Table 195 Change Ignored to Reserved. There is no reason an expander cannot mask off these bits for reads and ignore them for writes. HPQ comment number 44 Page=482 Subtype=Text Author=relliott Comment= 10.4.3.5 DISCOVER function Table 177 - ATTACHED DEVICE TYPE field Add: 111b Phy vacant (no device ever attached) HPQ comment number 45 Page=483 Subtype=Text Author=relliott Comment= 10.4.3.5 DISCOVER function Table 178 - NEGOTIATED PHYSICAL LINK RATE field Add 7h or Fh as "Phy vacant (phy is never going to be enabled)" HPQ comment number 46 Page=484 Subtype=Text Author=relliott Comment= 10.4.3.5 DISCOVER function After table 179 - ATTACHED SATA PORT SELECTOR and ATTACHED SATA DEVICE bits Add: If either the ATTACHED SATA PORT SELECTOR bit or the ATTACHED SATA DEVICE bit is set to one, then all the ATTACHED SSP/STP/SMP INITIATOR/TARGET PORT bits shall be set to zero (and vice-versa). HPQ comment number 47 Page=488 Subtype=Highlight Author=RElliott Comment= 10.4.3.6 REPORT PHY ERROR LOG function The Phy Layer Ready confirmation really comes from SP not SP_DWS HPQ comment number 48 Page=574 Subtype=Text Author=relliott Comment= L.3 Discover process C code Update to detect when two table route phys are connected together and ignore the connection beyond the initiator. The current code loops continuously when a table to table connection is made. ************************************************************** Comments attached to No ballot from George O. Penokie of IBM Corp.: IBM comment number 1 Page=32 Subtype=Text Author=George Penokie Comment=The revision information needs to be removed. IBM comment number 2 Page=43 Subtype=Highlight Author=George Penokie Comment= 2.4 Other references This << OMG Unified Modeling Language (UML) Specification. Version 1.5, March 2003. >> should be << OMG Unified Modeling Language (UML) Specification. Version 2.0, October 2004. >> IBM comment number 3 Page=48 Subtype=Highlight Author=George Penokie Comment= 3.1.52 duty cycle distortion (DCD): This << width of a '1' pulse or a '0' pulse and >> should be << width of a 1 pulse or a 0 pulse and >> or << width of a one pulse or a zero pulse and >> IBM comment number 4 Page=48 Subtype=Highlight Author=George Penokie Comment= 3.1.58 enclosure: Add << An enclosure is not a SAS or SCSI class. >> IBM comment number 5 Page=50 Subtype=Text Author=George Penokie Comment= The glossary is not the place to define everything there is to know about jitter. It should only have a short definition of relevant terms. The details should be in a section of the standard that describes jitter. It is a bad sign when a term is only used in the glossary section and nowhere else. IBM comment number 6 Page=50 Subtype=Text Author=George Penokie Comment= 3.1.100 jitter, data dependent (DDJ): This glossary entry has way too much information for a glossary entry. Also the only place where DDJ is used in other glossary entries. Everything after the first sentence should be in a section in the body of the standard. IBM comment number 7 Page=50 Subtype=Highlight Author=George Penokie Comment= 3.1.100 jitter, data dependent (DDJ): This << (one ISI mechanism). >> should be << (i.e., one ISI mechanism). >> IBM comment number 8 Page=50 Subtype=Highlight Author=George Penokie Comment= 3.1.100 jitter, data dependent (DDJ): This << mechanisms such as reflections, and transfer functions of coupling circuits and other mechanisms such as ground bounce. >> should be <> IBM comment number 9 Page=50 Subtype=Highlight Author=George Penokie Comment= 3.1.100 jitter, data dependent (DDJ): This << For example, when using media that attenuates the peak amplitude of the bit sequence consisting of repeating 0101b patterns more than peak amplitude of the bit sequence consisting of repeating 00001111b patterns, the time required to reach the receiver threshold with the 0101b patterns is less than required from the 00001111b patterns. The run length of 4 produces a higher amplitude that takes more time to overcome when changing bit values and therefore produces a time difference compared to the run length of 1 bit sequence. >> should be << (e.g., when using media that attenuates the peak amplitude of the bit sequence consisting of repeating 0101b patterns more than peak amplitude of the bit sequence consisting of repeating 00001111b patterns, the time required to reach the receiver threshold with the0101b patterns is less than required from the 00001111b patterns. The run length of four produces a higher amplitude that takes more time to overcome when changing bit values and therefore produces a time differencecompared to the run length of one bit sequence). >> IBM comment number 10 Page=50 Subtype=Highlight Author=George Penokie Comment= 3.1.100 jitter, data dependent (DDJ): This << pattern. For example, DDJ may be caused by the time differences required for the signal to arrive at the receiver threshold when starting from different places in bitsequences (symbols). >> should be << pattern (e.g., DDJ may be caused by the time differences required for the signal to arrive at the receiver threshold when starting from different places in bit sequences (i.e., symbols)). >> IBM comment number 11 Page=50 Subtype=StrikeOut Author=George Penokie Comment= 3.1.96 intersymbol interference (ISI): This << Important mechanisms that produce ISI are dispersion, reflections, and circuits that lead tobaseline wander. >> should be deleted as it has no value to the standard. IBM comment number 12 Page=50 Subtype=Highlight Author=George Penokie Comment= 3.1.96 intersymbol interference (ISI): This << Neighboring means close enough to have significant >> should be << Neighboring pulses are pulses that are close enough to have significant >> IBM comment number 13 Page=50 Subtype=Highlight Author=George Penokie Comment= 3.1.96 intersymbol interference (ISI): This << pulses - many bit times may separate the pulses especially in the case of reflections. >> should be << pulses (i.e., many bit times may separate the pulses especially in the case of reflections). >> IBM comment number 14 Page=50 Subtype=Highlight Author=George Penokie Comment= 3.1.94 insertion loss, differential (SDD21): This << measured at port 2.>> should be << measured at port two.>> IBM comment number 15 Page=50 Subtype=Highlight Author=George Penokie Comment= 3.1.94 insertion loss, differential (SDD21): This << measured at port 1.>> should be << measured at port one.>> IBM comment number 16 Page=50 Subtype=Highlight Author=George Penokie Comment= 3.1.93 insertion loss (S21): This << The ratio (expressed in dB) of delivered power >> should be << The ratio, expressed in dB, of delivered power >> IBM comment number 17 Page=51 Subtype=Highlight Author=George Penokie Comment= 3.1.110 jitter tolerance for receiver devices: This << See also signal tolerance. >> is not a valid cross reference and needs to be fixed. IBM comment number 18 Page=51 Subtype=Text Author=George Penokie Comment= 3.1.110 jitter tolerance for receiver devices: Just about everything after the first sentence should not be in a glossary but should be included in a section on jitter. IBM comment number 19 Page=51 Subtype=Text Author=George Penokie Comment= 3.1.109 jitter tolerance at transmit device compliance points: Just about everything after the first sentence should not be in a glossary but should be included in a section on jitter. IBM comment number 20 Page=51 Subtype=Highlight Author=George Penokie Comment= 3.1.109 jitter tolerance at transmit device compliance points: This << See also signal tolerance. >> is not a valid cross reference and needs to be fixed. IBM comment number 21 Page=51 Subtype=Highlight Author=George Penokie Comment= 3.1.107 jitter, total (TJ): It is not clear what this statement << (1 - jitter eye opening) >> relates to or what information it is tryingto convey. This needs to be fixed. IBM comment number 22 Page=51 Subtype=Highlight Author=George Penokie Comment= 3.1.106 jitter, random, (RJ): This << distribution and is unbounded. Examples of mechanisms that can cause RJ include PLL jitter in transmitter devices, electronic switching noise, and analog amplifiers. >> should be << distribution and is unbounded (e.g., may be caused by PLL jitter in transmitter devices, electronic switching noise, and analog amplifiers). >> IBM comment number 23 Page=52 Subtype=StrikeOut Author=George Penokie Comment= 3.1.127 object diagram: This << ; a special case of a class diagram >> should be deleted as it is not really accurate. The remaining is good enough. IBM comment number 24 Page=54 Subtype=Highlight Author=George Penokie Comment= 3.1.156 retimer: This << In the context of jitter methodology, a retimer resets the accumulation of jitter such that the output of a retimer has the jitter budget of a compliant transmitter device. All SAS receiverdevices shall be retimers. >> should be moved to a section on jitter. Putting requirements in a glossary enter is a very bad idea. IBM comment number 25 Page=56 Subtype=Highlight Author=George Penokie Comment= 3.1.202 signal tolerance: None of this belongs in the glossary and should in placed in the main body of the standard possibly in a jitter section. << Signal tolerance is measured by the amount of jitter required toproduce a specified bit error ratio at a specified signal amplitude andother signal properties. The signal tolerance performance depends on the frequency content of the jitter and on the amplitude of the signal. Since detection of bit errors is required to determine the signal tolerance, receiver circuits embedded in a SAS protocol chips require that the protocol chip be capable of reporting bit errors. For receiver circuits that are not embedded in a SAS protocol chip the bit error detection and reporting may be accomplished by instrumentation attached to the output of the receiver circuit. Signal tolerance is measured using the minimum allowed applied signal eye opening for both horizontal and vertical directions unless otherwise specified. >> IBM comment number 26 Page=61 Subtype=Highlight Author=George Penokie Comment= 3.2 Symbols and abbreviations This should be deleted << SP_DWS phy layer dword synchronization state machine (see 6.9) >> as it is the name of a state machine which we should not be adding into this list as it isnot an abbreviation. IBM comment number 27 Page=62 Subtype=Highlight Author=George Penokie Comment= 3.3.6 need not: This should not be a keyword. It should be deleted and all usages replaced with. << is not required to >> IBM comment number 28 Page=63 Subtype=Highlight Author=George Penokie Comment= 3.4 Editorial conventions Global This << Western-Arabic >> should be <<< Arabic >> per the ISO part 2 version 5 style guide. IBM comment number 29 Page=63 Subtype=StrikeOut Author=George Penokie Comment= 3.3.11 shall: This << (equivalent to "is required to"). >>should be deleted as it adds nothing and is not used in other standards whendefining the shall keyword. IBM comment number 30 Page=74 Subtype=Highlight Author=George Penokie Comment= 4.1.1 Architecture overview Figure 10 This << 1..* >> should be << 1.. 65 353>> IBM comment number 31 Page=74 Subtype=Highlight Author=George Penokie Comment= 4.1.1 Architecture overview Figure 10 This << 1..* >> should be << 1.. 65 353>> IBM comment number 32 Page=78 Subtype=Text Author=George Penokie Comment= 4.1.3 Ports (narrow ports and wide ports) Having all this space between the start of a sentence and the end of the sentence is not a good idea. Move the table anchor to it's own paragraph and this will not be a problem. IBM comment number 33 Page=78 Subtype=Highlight Author=George Penokie Comment= 4.1.3 Ports (narrow ports and wide ports) This <> should be <> IBM comment number 34 Page=78 Subtype=Highlight Author=George Penokie Comment= 4.1.3 Ports (narrow ports and wide ports) This << need not >> should be changed to << are not required to >> IBM comment number 35 Page=79 Subtype=Text Author=George Penokie Comment= 4.1.3 Ports (narrow ports and wide ports) Having all this space between the start of a list and the end of the list is not a good idea. Movethe table anchor to it's own paragraph and this will not be a problem. IBM comment number 36 Page=83 Subtype=Text Author=George Penokie Comment= 4.1.5 Expander devices (edge expander devices and fanout expander devices) Having all this space between the start of a list and the end of the list is not a good idea. Move the table anchor to it's own paragraphand this will not be a problem. IBM comment number 37 Page=90 Subtype=Highlight Author=George Penokie Comment= 4.1.8.3 Expander device topologies Figure 26 Figure 26 is identical to figure 23. Delete figure 26 and change the references to figure 26 to reference figure 23. IBM comment number 38 Page=93 Subtype=Highlight Author=George Penokie Comment= 4.1.10 Connections Figure 28 Change << Notes >> to << Note >> IBM comment number 39 Page=94 Subtype=Highlight Author=George Penokie Comment= 4.2.2 SAS addresses This << Information about IEEE company identifiers may be obtained from the http://standards.ieee.org/regauth/oui web site. >> should be made into a note. IBM comment number 40 Page=108 Subtype=Highlight Author=George Penokie Comment= 4.5 I_T nexus loss This << An I_T nexus loss based on the aforementioned conditions handled by the port layer state machine (see 8.2.2.3). >> does not make sense even after changing << aforementioned >> to << inthis subclause >>. Maybe << conditions handled by >> should be << conditions is handled by >> IBM comment number 41 Page=108 Subtype=Highlight Author=George Penokie Comment= 4.4.2 Hard reset This << SCSI application layer (see 10.2.5); the SCSI device shall perform the >> should be << SCSI application layer (see 10.2.5) and the SCSI device shall perform the >> IBM comment number 42 Page=108 Subtype=Highlight Author=George Penokie Comment= 4.5 I_T nexus loss This << SCSI application layer (see 10.2.5); the SCSI device shall perform >> should be << SCSI application layer (see 10.2.5) and the SCSI device shall perform >> IBM comment number 43 Page=119 Subtype=Highlight Author=George Penokie Comment= 4.6.7.2 Connection request routing This << (i.e., the DISCOVER function reports a NEGOTIATED PHYSICAL LINK RATE field set to 8h or 9h) >> should change to an << (e.g., .. ) >> because in the future, when we go to higher speeds who is going to remember to add the new speed here? IBM comment number 44 Page=121 Subtype=Text Author=George Penokie Comment= 4.7.1 Discover process overview Figure 45 The note in this figure implies that all the phys are indicated by numbers. However, there are several places were there appear to be multiple links but only one phy number. There also appears to be unconnected phys that are not numbered. This all needs to be fixed. IBM comment number 45 Page=121 Subtype=Text Author=George Penokie Comment= 4.7.1 Discover process overview Figure 45 This figure needs to indicate where the expander device set boundaries are. Otherwise it this couldbe interpreted as allowing illegal topologies. IBM comment number 46 Page=122 Subtype=Highlight Author=George Penokie Comment= 4.7.1 Discover process overview This << need not >> should be changed to << is not required to >> IBM comment number 47 Page=124 Subtype=Highlight Author=George Penokie Comment= 4.7.4 Expander route index order This << If the phy is not attached to an edge expander device, every >> would be clearer stated as << If theedge expander device phy is not attached, every >> IBM comment number 48 Page=124 Subtype=Highlight Author=George Penokie Comment= 4.7.4 Expander route index order This << phy (in either a fanout expander device or an edge expander device) that >> should be << phy, in either a fanout expander device or an edge expander device, that >> IBM comment number 49 Page=131 Subtype=Highlight Author=George Penokie Comment= 5.2.1 SATA cables and connectors This << SAS initiator device; a SATA device is analogous to a SAS target device. >> should be << SAS initiator device and a SATA device is analogous to a SAS target device. >> IBM comment number 50 Page=133 Subtype=Highlight Author=George Penokie Comment= 5.2.2 SAS cables and connectors Figure 53 This << (symmetric SAS internal wide cable connects the Tx signal pins to the Rx signal pins within each physical link) >> should be << NOTE: symmetric SAS internal widecable connects the Tx signal pins to the Rx signal pins within each physical link. >> IBM comment number 51 Page=133 Subtype=Highlight Author=George Penokie Comment= 5.2.2 SAS cables and connectors Figure 52 This << (SAS external cable connects the Tx signal pins to the Rx signal pins on each physical link) >> should be << NOTE: SAS external cable connects the Tx signal pins to the Rx signal pins on each physical link. >> IBM comment number 52 Page=134 Subtype=Highlight Author=George Penokie Comment= 5.2.2 SAS cables and connectors Figure 55 This << (the cable connects the Tx signal pins to the Rx signal pins within each physical link) >> should be << NOTE: the cable connects the Tx signal pins to the Rx signal pins within each physical link. >> IBM comment number 53 Page=134 Subtype=Highlight Author=George Penokie Comment= 5.2.2 SAS cables and connectors Figure 54 This << (SAS internal wide cable connects the Tx signal pins to the Rx signal pins within each physical link) >> should be << NOTE: SAS internal wide cable connects the Tx signal pins to the Rx signal pins within each physical link. >> IBM comment number 54 Page=135 Subtype=Highlight Author=George Penokie Comment= 5.2.2 SAS cables and connectors Figure 55 This << (the cable connects the Tx signal pins to the Rx signal pins within each physical link) >> should be << NOTE: The cable connects the Tx signal pins to the Rx signal pins within each physical link. >> IBM comment number 55 Page=137 Subtype=Highlight Author=George Penokie Comment= 5.2.3.2.2 SAS internal cable receptacle connector This << receptacle connector on the SAS target device end. The SAS internal cable receptacleconnectors are defined in SFF-8482. >> should be << receptacle connector (see SFF-8482) on the SAS target device end.>> to make the word consistent with other sections. IBM comment number 56 Page=137 Subtype=Highlight Author=George Penokie Comment= 5.2.3.2.1 SAS plug connector This << plug connector. The SAS plug connector is defined in SFF-8482. It >> should be << plug connector (see SFF-8482). It >> to make the word consistent with other sections. IBM comment number 57 Page=140 Subtype=Highlight Author=George Penokie Comment= 5.2.3.3.3 SAS external receptacle connector This << The SAS external receptacle connector is defined in SFF-8470 as the four lane fixed (receptacle) connector with jack screws. >> should be << The SAS external receptacle connector (see SFF-8470) is a four lane fixed (receptacle)connector with jack screws. >> IBM comment number 58 Page=140 Subtype=Highlight Author=George Penokie Comment= 5.2.3.3.2 SAS external cable plug connector This << The SAS external cable plug connector is defined in SFF-8470 as the four lane free (plug) connector with jack screws. >> should be << The SAS external cable plug connector (see SFF-8470) is a four lane free (plug) connector with jack screws. >> IBM comment number 59 Page=141 Subtype=Text Author=George Penokie Comment= 5.2.3.3.4 SAS external connector pin assignments More of those needless broken up sentences that should be fixed. IBM comment number 60 Page=142 Subtype=Highlight Author=George Penokie Comment= 5.2.3.3.5 SAS external compact cable plug connector This << Key slots are not defined by this standard. >> is not correct and should be deleted. The last paragraph states there are defined key slots. IBM comment number 61 Page=142 Subtype=Highlight Author=George Penokie Comment= 5.2.3.3.5 SAS external compact cable plug connector This << The SAS external compact cable plug connector with latch is defined in SFF-8088 asthe free (plug) cable connector. >> should be << The SAS external compact cable plug connector with latch (see SFF-8088) is a free (plug)cable connector. >> IBM comment number 62 Page=143 Subtype=Highlight Author=George Penokie Comment= 5.2.3.3.6 SAS external compact receptacle connector This << Key slots are not defined by this standard. >> is not correct and should be deleted. The last paragraph states there are defined key slots. IBM comment number 63 Page=143 Subtype=Highlight Author=George Penokie Comment= 5.2.3.3.6 SAS external compact receptacle connector This << SFF-8086 defines the receptacle mating interface (the receptacle body is common to both internal and external connectors). >> should be << SFF-8086 defines the receptacle mating interface in which the receptacle body is common to both internal and external connectors. >> IBM comment number 64 Page=143 Subtype=Highlight Author=George Penokie Comment= 5.2.3.3.6 SAS external compact receptacle connector This << The SAS external compact connector is defined in SFF-8088 as the fixed (receptacle) right angle connector. >> should be << The SAS external compact connector (see SFF-8088) is a fixed (receptacle) right angle connector.>> IBM comment number 65 Page=144 Subtype=Text Author=George Penokie Comment= 5.2.3.3.7 SAS external compact connector pin assignments More of those needless broken up sentences that should be fixed. IBM comment number 66 Page=146 Subtype=Highlight Author=George Penokie Comment= 5.2.3.3.8 External compact connector keying This should be deleted <> as the figure is correct. IBM comment number 67 Page=146 Subtype=Highlight Author=George Penokie Comment= 5.2.3.3.8 External compact connector keying This should be deleted <> as the figure is correct. IBM comment number 68 Page=147 Subtype=Highlight Author=George Penokie Comment= 5.2.3.4.2 SAS internal wide cable receptacle connector This << The SAS internal wide cable receptacle connector is defined in SFF-8484. The SAS internal wide cable receptacle connector attaches to a SAS internal wide plug connector, >> should be << The SAS internal wide cable receptacle connector (see SFF-8484) attaches to a SAS internal wide plug connector, >> IBM comment number 69 Page=147 Subtype=Highlight Author=George Penokie Comment= 5.2.3.3.8 External compact connector keying This should be deleted <> as the figure is correct. IBM comment number 70 Page=148 Subtype=Text Author=George Penokie Comment= 5.2.3.4.4 SAS internal wide connector pin assignments More of those needless broken up sentences that should be fixed. IBM comment number 71 Page=148 Subtype=Highlight Author=George Penokie Comment= 5.2.3.4.3 SAS internal wide plug connector This << The SAS internal wide plug connector is defined in SFF-8484. The SAS internal wide plug connector attaches to a SAS internal wide cable receptacle connector, >> should be << The SAS internal wide plug connector (see SFF-8484) attaches to a SAS internal wide cable receptacle connector, >> IBM comment number 72 Page=150 Subtype=Highlight Author=George Penokie Comment= 5.2.3.4.5 SAS internal compact wide cable plug connector This << The SAS internal compact wide cable plug connector assembly is defined in SFF-8087 as the fixed >> should be << The SAS internal compact wide cable plug connector assembly (see SFF-8087) is a fixed >> IBM comment number 73 Page=151 Subtype=Highlight Author=George Penokie Comment= 5.2.3.4.6 SAS internal compact wide receptacle connector This << The SAS internal compact wide receptacle connector is defined in SFF-8087 as the fixed (receptacle) right >> should be << The SAS internal compact wide receptacle connector (see SFF-8087) is a fixed (receptacle) right >> IBM comment number 74 Page=152 Subtype=Text Author=George Penokie Comment= 5.2.3.4.7 SAS internal compact wide connector pin assignments More of those needless broken up sentences that should be fixed. IBM comment number 75 Page=153 Subtype=Highlight Author=George Penokie Comment= 5.2.3.4.7 SAS internal compact wide connector pin assignments This << Editor's Note 4: signal assignments may be incorrect >> should be deleted as the information in the table is correct. IBM comment number 76 Page=154 Subtype=Highlight Author=George Penokie Comment= 5.2.3.4.7 SAS internal compact wide connector pin assignments Table 29 All the pin positions are incorrect in this table. Recommend adopting 05-139 as solution. IBM comment number 77 Page=154 Subtype=Highlight Author=George Penokie Comment= 5.2.3.4.7 SAS internal compact wide connector pin assignments This << Editor's Note 5: signal assignments may be incorrect >> should be deleted as the information in the table is correct. IBM comment number 78 Page=155 Subtype=Text Author=George Penokie Comment= 5.2.4.1 SAS internal cables The shall in this section relating to the internal connectors gives the impression that all internal cables are required to have SATA style cable receptacles. This is not the case as thewide internal cables do not have that requirement. This needs to be fixed but either clearly labeling this as a specific kind of internal cableor removing the shall altogether. IBM comment number 79 Page=158 Subtype=Highlight Author=George Penokie Comment= 5.2.4.3.1 SAS internal wide cables overview This << other end (e.g., a Tx + of one connector shall connect to an Rx + of the other connector.The physical link number of the signal depends on the application - controller-to-controller and controller-to-backplane differ). >> should be<< other end (e.g., a Tx + of one connector shall connect to an Rx + of the other connector). The physical link number of the signal depends on the application (e.g., controller-to-controller and controller-to-backplane differ). >> IBM comment number 80 Page=160 Subtype=Square Author=George Penokie Comment= 5.2.4.3.2 SAS internal wide symmetric cables This << NOTE 9 - For controller to controller uses, all four physical links should be used, because one controllers physical link 0 is attached the other controllers physical link 3. If both controllers used only physical link 0, they would not communicate. >> should be << NOTE 9 - For controller to controller uses, all four physical links should be used, because one controllers physical link 0 is attached the other controller's physical link 3. If both controllers used only physical link 0, then communication is not possible. >> IBM comment number 81 Page=161 Subtype=Highlight Author=George Penokie Comment= 5.2.4.3.2 SAS internal wide symmetric cables This << Editor's Note 6: signal assignments may be incorrect >> should be deleted as the information in the figure is correct. IBM comment number 82 Page=162 Subtype=Highlight Author=George Penokie Comment= 5.2.4.3.2 SAS internal wide symmetric cables This << Editor's Note 7: signal assignments may be incorrect >> should be deleted as the information in the figure is correct. IBM comment number 83 Page=165 Subtype=Highlight Author=George Penokie Comment= 5.2.4.3.3 SAS internal wide controller-based fanout cables This << Editor's Note 8: signal assignments may be incorrect >> should be deleted as the information in the figure is correct. IBM comment number 84 Page=166 Subtype=Highlight Author=George Penokie Comment= 5.2.4.3.4 SAS internal wide backplane-based fanout cables This << Editor's Note 9: signal assignments may be incorrect >> should be deletedas the information in the figure is correct. IBM comment number 85 Page=167 Subtype=Highlight Author=George Penokie Comment= 5.2.4.3.5 SAS internal compact wide cable keying This <> should be deleted as the figure is correct. IBM comment number 86 Page=168 Subtype=Highlight Author=George Penokie Comment= 5.2.4.3.5 SAS internal compact wide cable keying This <> should be deleted as the figure is correct. IBM comment number 87 Page=169 Subtype=Highlight Author=George Penokie Comment= Global Many of the footnote references overlay the table header line separators. This needs to be fixed as many of the b's and d's could be misinterpreted to be a's. IBM comment number 88 Page=177 Subtype=Highlight Author=George Penokie Comment= 5.3.1 Compliance points This << device is attached; SATA defines >> should be << device is attached because SATA defines >> IBM comment number 89 Page=180 Subtype=Highlight Author=George Penokie Comment= 5.3.2.1 Test loads overview There is no definition or description for the term << Gen2i >> this needs to be fixed. IBM comment number 90 Page=186 Subtype=Highlight Author=George Penokie Comment= 5.3.3 General electrical characteristics This << impedance dip (amplitude as ρ, the reflection coefficient, and duration in time) caused >> should be << impedance dip (i.e., amplitude as ρ, the reflection coefficient, and duration in time) caused >> IBM comment number 91 Page=187 Subtype=Highlight Author=George Penokie Comment= 5.3.4 Transmitter and receiver device transients This << GROUND on the test loads shown in figure 98 (for the transmitter device) and figure99 (for the receiver device) during all power state and mode transitions. >> should be << GROUND on the test loads for the transmitter device (see figure 98) and for the receiver device (figure 99) during allpower state and mode transitions. >> IBM comment number 92 Page=188 Subtype=Text Author=George Penokie Comment= 5.3.6.3 Receiver device eye mask Having all this space between the start of a sentence and the end of the sentence is not a good idea. Move the table anchor to it's own paragraph and this will not be a problem. IBM comment number 93 Page=190 Subtype=Square Author=George Penokie Comment= 5.3.6.4 Receiver device jitter tolerance eye mask The << d) >> and << e) >> should be deleted. This is not an unordered list. IBM comment number 94 Page=191 Subtype=Text Author=George Penokie Comment= 5.3.7.3 Transmitter device signal output characteristics as measured with each test load Having all this space between the start of a sentenceand the end of the sentence is not a good idea. Move the table anchor to it's own paragraph and this will not be a problem. IBM comment number 95 Page=192 Subtype=Highlight Author=George Penokie Comment= 5.3.7.3 Transmitter device signal output characteristics as measured with each test load Figure 38 This << Serial ATA >> should be <> IBM comment number 96 Page=192 Subtype=Highlight Author=George Penokie Comment= 5.3.7.3 Transmitter device signal output characteristics as measured with each test load Figure 38 This << Serial ATA >> should be <> IBM comment number 97 Page=192 Subtype=Highlight Author=George Penokie Comment= 5.3.7.3 Transmitter device signal output characteristics as measured with each test load Table 38 This <> should be <> IBM comment number 98 Page=192 Subtype=Highlight Author=George Penokie Comment= 5.3.7.3 Transmitter device signal output characteristics as measured with each test load Table 38 This <> should be <> IBM comment number 99 Page=192 Subtype=Highlight Author=George Penokie Comment= 5.3.7.3 Transmitter device signal output characteristics as measured with each test load Table 38 This <> should be <> IBM comment number 100 Page=192 Subtype=Highlight Author=George Penokie Comment= 5.3.7.3 Transmitter device signal output characteristics as measured with each test load Table 38 This <> should be <> IBM comment number 101 Page=193 Subtype=Highlight Author=George Penokie Comment= 5.3.7.4 Transmitter device maximum jitter There is no definition or description for the term << Gen1i >> this needs to be fixed. IBM comment number 102 Page=194 Subtype=Highlight Author=George Penokie Comment= 5.3.8.1 Receiver device characteristics overview This << The figure given assumes that any external >> should be << The value given assumes that any external >> IBM comment number 103 Page=194 Subtype=Highlight Author=George Penokie Comment= 5.3.8.1 Receiver device characteristics overview This << The jitter tolerance figure is listed in figure 102 for all >> should be << The jitter tolerance value is listed in figure 102 for all >> IBM comment number 104 Page=195 Subtype=Highlight Author=George Penokie Comment= 5.3.8.2 Delivered signal characteristics Figure 40 This << Serial ATA >> should be <> IBM comment number 105 Page=195 Subtype=Highlight Author=George Penokie Comment= 5.3.8.2 Delivered signal characteristics Figure 40 This << Serial ATA >> should be <> IBM comment number 106 Page=196 Subtype=Text Author=George Penokie Comment= 5.3.8.4 Receiver device jitter tolerance Having all this space between the start of a sentence and the end of the sentence is not a good idea.Move the table anchor to it's own paragraph and this will not be a problem. IBM comment number 107 Page=197 Subtype=Highlight Author=George Penokie Comment= 5.3.10 Non-tracking clock architecture This << need not >> should be changed to << are not required to >> IBM comment number 108 Page=197 Subtype=Highlight Author=George Penokie Comment= 5.3.9 Spread spectrum clocking This << need not >> should be changed to << are not required to >> IBM comment number 109 Page=200 Subtype=Square Author=George Penokie Comment= 6.2.3 8b10b coding notation conventions The list after the << where >> should not be an a,b,c list. It should be indented and start with the named variable followed by a description with some space between See Style Guide (o5-085) for examples. IBM comment number 110 Page=201 Subtype=StrikeOut Author=George Penokie Comment= 6.3.3 Data and control characters Move this << Otherwise >> to end of item b). IBM comment number 111 Page=201 Subtype=Highlight Author=George Penokie Comment= 6.3.3 Data and control characters This << four-bit sub-block is 1100b. >> should be << four-bit sub-block is 1100b; otherwise >> IBM comment number 112 Page=201 Subtype=Highlight Author=George Penokie Comment= 6.3.3 Data and control characters This << four-bit sub-block is 0011b. >> should be << four-bit sub-block is 0011b; >> IBM comment number 113 Page=208 Subtype=Highlight Author=George Penokie Comment= 6.4 Dwords, primitives, data dwords, and invalid dwords This << which are used in SAS during STP connections >> should be << which are only used in SAS during STP connections >> IBM comment number 114 Page=213 Subtype=Highlight Author=George Penokie Comment= 6.6.3 Receiving OOB signals This << detected; another COMINIT may follow). >> should be << detected after which another COMINIT may follow).>> IBM comment number 115 Page=217 Subtype=StrikeOut Author=George Penokie Comment= 6.7.2.2 SATA speed negotiation sequence This <
> along with figure 110, table 57, and the text between the figure and table should be deleted as it is information that is (or should be) defined in the referenced standards. IBM comment number 116 Page=217 Subtype=Highlight Author=George Penokie Comment= 6.7.2.2 SATA speed negotiation sequence This << defined by SATA; see ATA/ATAPI-7 V3 and SATA2-PHY for detailed requirements. >> should be << defined by SATA (see ATA/ATAPI-7 V3 and SATA2-PHY for detailed requirements). >> IBM comment number 117 Page=226 Subtype=StrikeOut Author=George Penokie Comment= 6.8.1 SP state machine overview This << A COMWAKE Detected message received in SP0:OOB_COMINIT or SP1:OOB_AwaitCOMX shall set the COMWAKE_Received state machine variable to one. Any transition to SP0:OOB_COMINIT shall set the COMWAKE_Received state machine variable to zero. >> should be deleted and, if not already there, be placed in the relevant state transitions. IBM comment number 118 Page=226 Subtype=Highlight Author=George Penokie Comment= 6.8.1 SP state machine overview This << Any transition out of SP7:OOB_AwaitCOMSAS shall set the MgmtReset state machine variable to zero. >> seems to contradict when is currently in SP0 and implies that the MgntResedt is always set to zero when SP0 is exited. This seems to nullify it usefulness. I think the sentence should be deleted. IBM comment number 119 Page=226 Subtype=Highlight Author=George Penokie Comment= 6.8.1 SP state machine overview This is a mess << The SP state machine shall maintain a MgmtReset state machine variable to indicate whether SP0:OOB_COMINIT was last entered due to a Management Reset, or a defined transition from another state (see 6.8.3.2.1). If SP0:OOB_COMINIT was last entered due to a Management Reset, it shall set the MgmtReset statemachine variable to one. If SP0:OOB_COMINIT was last entered by a defined transition from another state, it shall set the MgmtReset state machine variable to zero. >>. I think it should be restated like this << TheSP state machine shall maintain a MgmtReset state machine variable to indicate whether when Management Reset request is received. Any SP state that receives a Management Reset request shall set the MgmtReset state machine variable to one before making the transition to the SP7:OOB_AwaitCOMSAS state. Any SP state that receives a power on, or a hard reset shall set the MgmtReset state machine variable to one the transition to the SP7:OOB_AwaitCOMSAS state. >> Note that the other cases that case theMgmtRest variable to be set to zero are not global and therefore have to be handled in the state were the action occurs in the description of the transition. IBM comment number 120 Page=227 Subtype=Highlight Author=George Penokie Comment= 6.8.2 SP transmitter and receiver This << SP transmitter transmits idle time. >> should be << SP transmitter transmits idle dwords.>> IBM comment number 121 Page=228 Subtype=Text Author=George Penokie Comment= 6.8.3.1 OOB sequence states overview Figure 117 The transition into SP0 from SP26 is missing. This needs to be fixed. IBM comment number 122 Page=228 Subtype=Text Author=George Penokie Comment= 6.8.3.1 OOB sequence states overview Figure 117 All the comments on the state to state transitions within this figure should be deleted. IBM comment number 123 Page=229 Subtype=Text Author=George Penokie Comment= 6.8.3.2.4 Transition SP0:OOB_COMINIT to SP4:OOB_COMSAS Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 124 Page=229 Subtype=Text Author=George Penokie Comment= 6.8.3.2.3 Transition SP0:OOB_COMINIT to SP3:OOB_AwaitCOMINIT_Sent Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 125 Page=229 Subtype=Square Author=George Penokie Comment= 6.8.3.2.1 State description The behavior defined in this paragraph <> should be deleted as it isduplicate information. Part of the information that covers global SP behavior is in the SP state machine. The remaining part has to be place into the state at which the event occurs before making the transition to SP0. IBM comment number 126 Page=229 Subtype=StrikeOut Author=George Penokie Comment= 6.8.3.2.1 State description This << or SMP Reset request. >> should be deleted as there is not sure thing as an SMP Reset in SAS. IBM comment number 127 Page=229 Subtype=Highlight Author=George Penokie Comment= 6.8.3.3.1 State description This << machine variable to one; and then if the value of the ATTACHED SATA PORT >> should be << machine variableto one, and if the value of the ATTACHED SATA PORT >> IBM comment number 128 Page=230 Subtype=Highlight Author=George Penokie Comment= 6.8.3.6.1 State description This << DISCOVER response, it shall set the ATTACHED >> should be << DISCOVER response, this state shall set the ATTACHED >> IBM comment number 129 Page=231 Subtype=Text Author=George Penokie Comment= 6.8.3.8.2 Transition SP6:OOB_AwaitNoCOMSAS to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machinevariable to zero before the transition. >> IBM comment number 130 Page=231 Subtype=Highlight Author=George Penokie Comment= 6.8.3.8.3 Transition SP6:OOB_AwaitNoCOMSAS to SP8:SAS_Start So what is the point of this statement <>? There is a implication that the state is supposed to remember it this occurred which is impossible. So what is supposed to happen is the message is missed? IBM comment number 131 Page=231 Subtype=Highlight Author=George Penokie Comment= 6.8.3.6.3 Transition SP4:OOB_COMSAS to SP6:OOB_AwaitNoCOMSAS This << send a SATA Port Selector Change confirmation to the link layer. >> should be << send a SATA Port Selector Change confirmation to the link layer before the transition. >> IBM comment number 132 Page=231 Subtype=Highlight Author=George Penokie Comment= 6.8.3.6.2 Transition SP4:OOB_COMSAS to SP5:OOB_AwaitCOMSAS_Sent This << response and send a SATA Port Selector Change confirmation to the linklayer. >> should be << response and send a SATA Port Selector Change confirmation to the link layer before the transition. >> IBM comment number 133 Page=232 Subtype=Highlight Author=George Penokie Comment= 6.8.3.9.5 Transition SP7:OOB_AwaitCOMSAS to SP26:SATA _SpinupHold This << This state shall send a SATA Spinup Hold confirmation to the link layer and perform this transition if. >> should be << This transition shall occur if: >> Also after the a.b.c list the following should be added << This state shall send a SATA Spinup Hold confirmation to the link layer before the transition. >> IBM comment number 134 Page=232 Subtype=Highlight Author=George Penokie Comment= 6.8.3.9.3 Transition SP7:OOB_AwaitCOMSAS to SP6:OOB_AwaitNoCOMSAS This << shall send a SATA Port Selector Change confirmation to the link layer. >> should be << shall send a SATA Port Selector Change confirmation to the link layer before the transition. >> IBM comment number 135 Page=232 Subtype=Highlight Author=George Penokie Comment= 6.8.3.9.3 Transition SP7:OOB_AwaitCOMSAS to SP6:OOB_AwaitNoCOMSAS This <> should be << state machine variable to zero before the transition. >> IBM comment number 136 Page=233 Subtype=Text Author=George Penokie Comment= 6.8.4.1 SAS speed negotiation states overview Figure 118 All the comments on the state to state transitions within this figure should be deleted. IBM comment number 137 Page=234 Subtype=Text Author=George Penokie Comment= 6.8.4.2.2 Transition SP8:SAS_Start to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 138 Page=234 Subtype=Text Author=George Penokie Comment= 6.8.4.4.2 Transition SP10:SAS_AwaitALIGN to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 139 Page=234 Subtype=StrikeOut Author=George Penokie Comment= 6.8.4.2.1 State description This <> contains no useful information and should be deleted. Any information it does have has already been stated in the description of the speednegotiation sequence above. IBM comment number 140 Page=235 Subtype=Text Author=George Penokie Comment= 6.8.4.6.2 Transition SP12:SAS_AwaitSNW to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 141 Page=235 Subtype=Text Author=George Penokie Comment= 6.8.4.5.2 Transition SP11:SAS_AwaitALIGN1 to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 142 Page=235 Subtype=StrikeOut Author=George Penokie Comment= 6.8.4.5.4 Transition SP11:SAS_AwaitALIGN1 to SP14:SAS_Fail This << This indicates that the other phy has not been able to lock at the current rate. >> should be deleted. Any information it does have has already been stated in the description of the speed negotiation sequence above IBM comment number 143 Page=236 Subtype=Text Author=George Penokie Comment= 6.8.4.7.2 Transition SP13:SAS_Pass to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 144 Page=237 Subtype=Text Author=George Penokie Comment= 6.8.4.9.2 Transition SP15:SAS_PHY_Ready to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 145 Page=238 Subtype=Text Author=George Penokie Comment= 6.8.5.1 SATA host emulation states overview Figure 119 All the comments on the state to state transitions within this figure should be deleted. IBM comment number 146 Page=239 Subtype=Text Author=George Penokie Comment= 6.8.5.4.2 Transition SP187:SATA_AwaitNoCOMWAKE to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 147 Page=239 Subtype=Text Author=George Penokie Comment= 6.8.5.3.2 Transition SP17:SATA_AwaitCOMWAKE to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 148 Page=239 Subtype=Text Author=George Penokie Comment= 6.8.5.5.2 Transition SP19:SATA_AwaitALIGN to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 149 Page=240 Subtype=Text Author=George Penokie Comment= 6.8.5.8.2 Transition SP22:SATA_PHY_Ready to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 150 Page=240 Subtype=Text Author=George Penokie Comment= 6.8.5.7.2 Transition SP21:SATA_TransmitALIGN to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 151 Page=240 Subtype=Text Author=George Penokie Comment= 6.8.5.6.2 Transition SP20:SATA_AdjustSpeed to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machinevariable to zero before the transition. >> IBM comment number 152 Page=241 Subtype=Text Author=George Penokie Comment= 6.8.5.10.2 Transition SP24:SATA_PM_Slumber to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machinevariable to zero before the transition. >> IBM comment number 153 Page=241 Subtype=Text Author=George Penokie Comment= 6.8.5.9.2 Transition SP23:SATA_PM_Partial to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 154 Page=242 Subtype=Highlight Author=George Penokie Comment= 6.8.6.3 Transition SP25:SATA_PortSelectionSignalPending to SP1:OOB_AwaitCOMX This transition shall occur when the phy completes transmission of the SATA port selection signal (SATA Port Selection Signal Transmitted). >> should be << This transition shall occur after receiving a SATA Port Selection Signal Transmitted message. >> IBM comment number 155 Page=242 Subtype=Highlight Author=George Penokie Comment= 6.8.6.2 Transition SPx: to SP25:SATA_PortSelectionSignalPending This << The phy shall transmit the SATA port selection signal. Thistransition shall set the ATTACHED SATA PORT SELECTOR bit in the DISCOVER response to zero. >> should be placed in the states overview and changed to << Upon entry into this state, this state shall: a) send a SATA port selection signal to the SP transmitter; and b) set the ATTACHED SATA PORT SELECTOR bit in the DISCOVER response to zero. >> IBM comment number 156 Page=242 Subtype=StrikeOut Author=George Penokie Comment= 6.8.6.2 Transition SPx: to SP25:SATA_PortSelectionSignalPending This << If the phy supports attachment of a SATA device and attachment of a SATA Port Selector, a transition shall occur from any SP state to this state upon receipt of an SMP PHY CONTROL function for the phy specifying a phy operation of TRANSMIT SATA PORT SELECTION SIGNAL. >> willbe redundant (see general comment on this section) and should be deleted. IBM comment number 157 Page=242 Subtype=Text Author=George Penokie Comment= 6.8.6.1 State description This section is not properly formatted and as such is different that any other state description section is SAS. This has be fixed. For one thing there should only be one state shown. The SPx representation is not correct. The SMP Phy Control request should be handled lke the Power on or hard reset or Management Reset request. And it should be placed in all the SP state machine figures not just this one. There is no description of the transmitter and receiver signals. The SPx to SP25 transition should not be here. It should be handled in the same fashion as the Power on or hard reset or Management Reset request. There are other points that I have not described that also need fixing. In general make it look like it belongs in SAS. IBM comment number 158 Page=242 Subtype=Text Author=George Penokie Comment= 6.8.6.1 State description Figure 120 All the comments on the state to state transitions within this figure should be deleted. IBM comment number 159 Page=243 Subtype=Circle Author=George Penokie Comment= 6.8.7.1 State description Figure 121 There is no description as to under what conditions the << (in expander phys) SATA Spinup Hold >> confirmation is sent. This needs to be fixed. IBM comment number 160 Page=243 Subtype=StrikeOut Author=George Penokie Comment= 6.8.7.1 State description Figure 121 This << Reset or >> on the transitions to SP0 should be deleted as it is handled in the general description of the power on or hard reset or Management Reset description in theSP overview. IBM comment number 161 Page=243 Subtype=Text Author=George Penokie Comment= 6.8.7.2 Transition SP26:SATA_SpinupHold to SP0:OOB_COMINIT Add into this section << The state machine shall set the MgmtReset state machine variable to zero before the transition. >> IBM comment number 162 Page=243 Subtype=StrikeOut Author=George Penokie Comment= 6.8.7.2 Transition SP26:SATA_SpinupHold to SP0:OOB_COMINIT This << a Management Reset request from the management layer, a hard reset, or a power on. If this transition is caused by a Management Reset Request from the management layer, the state machine shall set the MgmtReset state machine variable to one upon entry to SP0:OOB_COMINIT. Otherwise, the state machine shall set the MgmtReset state machine variable to zero upon entry to SP0:OOB_COMINIT. >> should be deleted as it is duplicate information that is stated in the general description of the Reset or Power on or hard reset or Management Reset request. IBM comment number 163 Page=243 Subtype=Square Author=George Penokie Comment= 6.8.7.1 State description Figure 121 The << Reset or Power on or hard reset or Management Reset >> request should be handled in this figure the same way it is in all the other SP figures. IBM comment number 164 Page=243 Subtype=StrikeOut Author=George Penokie Comment= 6.8.7.1 State description This << This state shall be entered from the SP7:OOB_AwaitCOMSAS state upon detection of a COMSAS detect timeout if the phy supports SATA, the phy supports SATA spinup hold, and the MgmtReset state machine variable is set to zero. >> should be deleted as it is already defined in the SP7 to SP26 description. The convention is to only specify the transition rule on the out not on the in. IBM comment number 165 Page=250 Subtype=Highlight Author=George Penokie Comment= 7.2.1 Primitives overview This << Primitives are not considered big-endian or little-endian; they are just >> should be << Primitives are not considered big-endian or little-endian, they are just >> IBM comment number 166 Page=275 Subtype=Highlight Author=George Penokie Comment= 7.5.1 CRC overview note 27 This << one's complement of R(x); this equation is specifying that the R(x) is inverted before it is transmitted. >> should be << one's complement of R(x) resulting in this equation specifying that the R(x) is inverted before it is transmitted. >>. IBM comment number 167 Page=277 Subtype=Highlight Author=George Penokie Comment= 7.5.1 CRC overview This << Thus, the first byte contains the least-significant bit. >> should be << As a result, the first byte contains the least-significant bit. >> IBM comment number 168 Page=287 Subtype=Highlight Author=George Penokie Comment= 7.8.3 OPEN address frame This << connection rate; the SAS target port should not close the connection just to reopen the connection at the saved connection rate. >> should be << connection rate (i.e., the SAS target port should not close the connection just to reopen the connection atthe saved connection rate). >> IBM comment number 169 Page=299 Subtype=Highlight Author=George Penokie Comment= 7.12.3 Arbitration fairness This << NOTE 31 - NOTE 1 Connection responses that are conclusively from the destination >> should be << NOTE 31 -Connection responses that are conclusively from the destination >> IBM comment number 170 Page=302 Subtype=Highlight Author=George Penokie Comment= 7.12.5.2 Edge expander devices This << OPEN_REJECT (BAD DESTINATION); it should reply with OPEN_REJECT (NO DESTINATION). >> should be <> IBM comment number 171 Page=303 Subtype=Text Author=George Penokie Comment= 7.12.6 Aborting a connection request Seemed to me there should be some wording here about the new BREAK stuff we just added in. IBM comment number 172 Page=303 Subtype=Highlight Author=George Penokie Comment= 7.12.6 Aborting a connection request This is not at all clear << Table 96 lists the responses to a BREAK being transmitted before a connectionresponse has been received.>> I believe it should be << Table 96 lists the responses to a BREAK being received before a connection response hasbeen received.>> IBM comment number 173 Page=303 Subtype=Highlight Author=George Penokie Comment= 7.12.5.3 Fanout expander devices This << OPEN_REJECT (BAD DESTINATION); it should reply with OPEN_REJECT (NO DESTINATION). >> should be <> IBM comment number 174 Page=305 Subtype=Highlight Author=George Penokie Comment= 7.12.7 Closing a connection This in not clear << Table 97 lists the responses to a CLOSE being transmitted. >> I believe it should be << Table 97 lists the responses to a CLOSE being received.>> IBM comment number 175 Page=306 Subtype=Highlight Author=George Penokie Comment= 7.12.8 Breaking a connection This statement in not at all clear << Table 98 lists the responses to a BREAK being transmitted after a connection has been established. >> I believe it should be changed to << Table 98 lists the responses to a BREAK being received after a connection has been established. >> IBM comment number 176 Page=306 Subtype=Highlight Author=George Penokie Comment= 7.12.8 Breaking a connection This is no longer correct << After transmitting BREAK, the originating phy shall ignore all incoming dwords except for BREAKs. >> It should be << After transmitting BREAK, the originating phy shall ignore all incoming dwords except for BREAKs and OPENs. >> IBM comment number 177 Page=315 Subtype=Highlight Author=George Penokie Comment= 7.14.4.3.3 Transition SL_CC1:ArbSel to SL_CC2:Selected This << arbitration wait time argument to the Open Connection request for >> should be << arbitration wait time argument from the Open Connection request for >> IBM comment number 178 Page=318 Subtype=Highlight Author=George Penokie Comment= 7.14.4.6.1 State description In the statement <> there is no indication as to when which message is to be sent. This needs to be fixed. IBM comment number 179 Page=319 Subtype=Highlight Author=George Penokie Comment= 7.15.1 XL state machine overview This << facilitated by the expander function - specifically the ECM and ECR. >> should be << facilitated by the expander function (i.e., the ECM and ECR). >> IBM comment number 180 Page=319 Subtype=Highlight Author=George Penokie Comment= 7.14.4.9.1 State description In the statement <> there is no indication as to when which message is to be sent. This needs to be fixed. IBM comment number 181 Page=326 Subtype=Highlight Author=George Penokie Comment= 7.15.4.1 State description This << If the Partial Pathway Timeout timer expires, timeout status is conveyed to the expander connection managervia the partial pathway timeout status argument in the Request Path request. >> should be << If the Partial Pathway Timeout timer expires a Request Path request shall be sent to the xxx with the partial pathway timeout status argument. >> IBM comment number 182 Page=326 Subtype=Highlight Author=George Penokie Comment= 7.15.4.1 State description This << set to IGNORE AWT; otherwise, the Retry Priority Status argument shall be set to NORMAL. >> should be << set to IGNORE AWT. If this state is entered from any other state then the Retry Priority Status argument shall be set to NORMAL. >> IBM comment number 183 Page=329 Subtype=Highlight Author=George Penokie Comment= 7.15.7.2 Transition XL4:Open_Reject to XL0:Idle This << This transition shall occur after OPEN_REJECT has been transmitted. >> should be << This transition shall occur after the OPEN_REJECT message has been sent tothe XL transmitter. >>. Note that there is no response from the XL transmitter in the XL state machine figure. So if you really want to want until the OPEN_REJECT is transmitted then that will have to be added into the figure and the XL transmitter section. IBM comment number 184 Page=329 Subtype=Highlight Author=George Penokie Comment= 7.15.6.6 Transition XL3:Open_Confirm_Wait to XL9:Break This << This transition shall occur after sending a Forward Break request. >> should be<< This transition shall occur after sending a Forward Break request tothe ????. >> IBM comment number 185 Page=330 Subtype=Highlight Author=George Penokie Comment= 7.15.9.1 State description This << ECR to a source phy, received by the source phy as confirmations: >> should be << ECR to a source phy thatare received by the source phy as confirmations: >> IBM comment number 186 Page=330 Subtype=Highlight Author=George Penokie Comment= 7.15.9.1 State description Several of the items in this a,b,c list contain long confusing lists of things written out in a single sentence. These should be made in A,B,C lists so the rules are clear. IBM comment number 187 Page=330 Subtype=Highlight Author=George Penokie Comment= 7.15.9.1 State description This << ECR to a source phy, received by the source phy as confirmations: >> should be << ECR to a source phy thatare received by the source phy as confirmations: >> IBM comment number 188 Page=331 Subtype=Highlight Author=George Penokie Comment= 7.15.9.6 Transition XL6:Open_Response_Wait to XL9:Break This << This transition shall occur after sending a Forward Break response. >> should be << This transition shall occur after sending a Forward Break responseto the ????. >> IBM comment number 189 Page=331 Subtype=Highlight Author=George Penokie Comment= 7.15.9.5 Transition XL6:Open_Response_Wait to XL7:Connected This << This transition shall occur after sending an Open Accept response. >> should be << This transition shall occur after sending an Open Accept response to the ????. >> IBM comment number 190 Page=331 Subtype=Highlight Author=George Penokie Comment= 7.15.9.4 Transition XL6:Open_Response_Wait to XL2:Request_Open This << This transition shall occur after sending a Backoff Reverse Path response. >> should be << This transition shall occur after sending a Backoff Reverse Path response to the ???. >> IBM comment number 191 Page=331 Subtype=Highlight Author=George Penokie Comment= 7.15.9.3 Transition XL6:Open_Response_Wait to XL1:Request_Path This << This transition shall occur after sending a Backoff Retry response, after releasing path resources. >> should be << This transition shall occurafter: a) sending a Backoff Retry response it the ???: and b) afterreleasing path resources. >> IBM comment number 192 Page=331 Subtype=Highlight Author=George Penokie Comment= 7.15.9.2 Transition XL6:Open_Response_Wait to XL0:Idle This << This transition shall occur after sending an Open Reject response. >> should be<< This transition shall occur after sending an Open Reject response to the ????. >> IBM comment number 193 Page=331 Subtype=Highlight Author=George Penokie Comment= 7.15.9.1 State description This << This state shall repeatedly send a Phy Status (Partial Pathway) response to the ECM. >> should be << Thisstate shall repeatedly send a Phy Status (Partial Pathway) response to the ECM until an AIP Received (Waiting On Partial) message is received. >> IBM comment number 194 Page=332 Subtype=Highlight Author=George Penokie Comment= 7.15.11.2 Transition XL8:Close_Wait to XL0:Idle This << This transition shall occur after sending a Forward Close request.>> should be << Thistransition shall occur after sending a Forward Close request to the ???.>> IBM comment number 195 Page=332 Subtype=Highlight Author=George Penokie Comment= 7.15.10.3 Transition XL7:Connected to XL9:Break This <> should be << Thistransition shall occur after sending a Forward Break request to the ????. >> IBM comment number 196 Page=333 Subtype=Highlight Author=George Penokie Comment= 7.15.11.3 Transition XL8:Close_Wait to XL9:Break This << This transition shall occur after sending a Forward Break request. >> should be<< This transition shall occur after sending a Forward Break request to the ????. >> IBM comment number 197 Page=333 Subtype=Highlight Author=George Penokie Comment= 7.15.13.1 State description This << Upon entry into this state, this state shall send: >> should be << Upon entry into this state, this state shall: >> IBM comment number 198 Page=344 Subtype=Highlight Author=George Penokie Comment= 7.16.7.5 SSP_D (DONE control) state machine This << the SSP transmitter is going to close the connection within 1 ms; other DONE Received confirmations >> should be << the SSP transmitter is going to close the connection within 1 ms. Other DONE Received confirmations >> IBM comment number 199 Page=348 Subtype=Highlight Author=George Penokie Comment= 7.16.7.10 SSP_TC (transmit credit control) state machine This << (e.g., if the Available argument indicates 5 RRDYs are to be transmitted this state machine sends 5 Transmit RRDY (Normal) messages to the SSP transmitter). >> should be << (e.g., if the Available argument indicates five RRDYs are to be transmitted this state machine sends five Transmit RRDY (Normal) messages to the SSP transmitter). >> IBM comment number 200 Page=348 Subtype=Highlight Author=George Penokie Comment= 7.16.7.8 SSP_RCM (receive frame credit monitor) state machine This <<(e.g., if this state machine has resources for 5 frames the maximum number of Rx Credit Control requests with the Available argument outstanding is 5). >> should be << (e.g., if this state machine has resources for five frames the maximum number of Rx Credit Control requests with theAvailable argument outstanding is five). >> IBM comment number 201 Page=352 Subtype=StrikeOut Author=George Penokie Comment= 7.17.4 Affiliations This << This avoids confusing the SATA device, which only knows about one SATA host. >> should be deleted as it has no value in a standard. IBM comment number 202 Page=352 Subtype=Highlight Author=George Penokie Comment= 7.17.3 STP flow control This<< within 21 dwords (for a SATA physical link)>> Should be << within 21 dwords for a SATA physical link>> IBM comment number 203 Page=352 Subtype=Highlight Author=George Penokie Comment= 7.17.3 STP flow control This << within 24 dwords (for a 1,5 Gbps physical link). >> should be << within 24 dwords for a 1,5 Gbps physical link. >> IBM comment number 204 Page=352 Subtype=Highlight Author=George Penokie Comment= 7.17.3 STP flow control This << within 24 dwords (for a 1,5 Gbps physical link). >> should be << within 24 dwords for a 1,5 Gbps physical link. >> IBM comment number 205 Page=359 Subtype=Highlight Author=George Penokie Comment= 7.18.4.3.4 SMP_IP3:Receive_Frame state This << this state receives fewer than 2 Data Dword Received messages after an SOF Received message andbefore an EOF Received message. >> should be << this state receives fewer than two Data Dword Received messages after an SOF Received message and before an EOF Received message. >> IBM comment number 206 Page=361 Subtype=Highlight Author=George Penokie Comment= 7.18.4.4.3 SMP_TP2:Transmit_Frame state This << If this state receives a Tx Frame request, this state shall send a Transmit Frame message to the SMP transmitter; then wait for a Frame Transmitted message. >> shouldbe << If this state receives a Tx Frame request, this state shall send a Transmit Frame message to the SMP transmitter then wait for a Frame Transmitted message. >> IBM comment number 207 Page=361 Subtype=Highlight Author=George Penokie Comment= 7.18.4.4.2.1 State description This << this state receives fewer than 2 Data Dword Received messages after an SOF Received message and before an EOF Received message. >> should be << this state receives fewer than two Data Dword Received messages after an SOF Received message and before an EOF Received message. >> IBM comment number 208 Page=369 Subtype=Highlight Author=George Penokie Comment= 8.2.2.3.3 PL_OC2:Overall_Control state connection established This << stop the I_T Nexus Loss timer for the SAS address (if the timer has been running); >> should be << if the timer has been running then stop theI_T Nexus Loss timer for the SAS address ; >> IBM comment number 209 Page=370 Subtype=Highlight Author=George Penokie Comment= 8.2.2.3.4 PL_OC2:Overall_Control state unable to establish a connection This << stop the I_T Nexus Loss timer (if the timer has been running); >> should be << if the timer has been running then stop the I_T Nexus Loss timer ; >> IBM comment number 210 Page=378 Subtype=Highlight Author=George Penokie Comment= 8.2.3.4.1 PL_PM3:Connected state description This << If this state receives a Tx Frame message, this state shall send a Tx Frame request to the link layer. >> should be << If this state receives a Tx Frame message, then this state shall send a Tx Frame request to the link layer. >> IBM comment number 211 Page=378 Subtype=Highlight Author=George Penokie Comment= 8.2.3.4.1 PL_PM3:Connected state description This << stop the Bus Inactivity Time Limit timer, if it is running; >> should be << if it is running then stop the Bus Inactivity Time Limit timer; >> IBM comment number 212 Page=379 Subtype=Highlight Author=George Penokie Comment= 8.2.3.4.1 PL_PM3:Connected state description This << or a Phy Disabled confirmation after sending a Transmission Status (Frame Transmitted) confirmation, but before this state receives an ACK Received or NAK Received confirmation, >> should be << or a Phy Disabled confirmation aftersending a Transmission Status (Frame Transmitted) confirmation, before this state receives an ACK Received or NAK Received confirmation, >> IBM comment number 213 Page=384 Subtype=Highlight Author=George Penokie Comment= 9.2.1 SSP frame format This << dataoffset >> should be in smallcaps. IBM comment number 214 Page=385 Subtype=StrikeOut Author=George Penokie Comment= 9.2.1 SSP frame format This << This may be useful when the SSP target port has more than one XFER_RDY frame outstanding (i.e., the SSP targetport has transmitted an XFER_RDY frame for each of two or more commandsand has not yet received all the write data for them). >> should be deleted as it has no value in a standard. IBM comment number 215 Page=386 Subtype=Highlight Author=George Penokie Comment= 9.2.2.1 COMMAND information unit This << target port comply with SAS-1.1 or later >> should be << target port comply with this standard >> IBM comment number 216 Page=387 Subtype=Highlight Author=George Penokie Comment= 9.2.2.1 COMMAND information unit This << (e.g., a six-byte CDB occupies the first six bytes of the CDB field; the remaining ten bytes are ignored; and the ADDITIONAL CDB BYTES field is not present).>> should be << (e.g., a six-byte CDB occupies the first six bytes of the CDB field,the remaining ten bytes are ignored, and the ADDITIONAL CDB BYTES fieldis not present).>> IBM comment number 217 Page=388 Subtype=Highlight Author=George Penokie Comment= 9.2.2.2 TASK information unit This << The TARGET RESET task management function defined in SAM-3 is not supported. >> is not correct as SAAM-3does not define target reset. SAM-2 does. I think this should be deleted rather than adding a reference to SAM-2. IBM comment number 218 Page=389 Subtype=Text Author=George Penokie Comment= 9.2.2.3 XFER_RDY information unit This statement << The information contained within a XFER_RDY shall be maintained across connections. >> needs to be added into the 1st paragraph of this section. IBM comment number 219 Page=390 Subtype=Text Author=George Penokie Comment= 9.2.2.5.1 RESPONSE information unit overview Having all this space between the start of a sentence and the end of the sentence is not a good idea. Move the table anchor to it's own paragraph and this will not be a problem. IBM comment number 220 Page=392 Subtype=StrikeOut Author=George Penokie Comment= 9.2.2.5.3 RESPONSE information unit RESPONSE_DATA format This << Other lengths are reserved for future standardization; >> should be deleted as it states nothing useful. All values that are reserved are reserved for future standardization. IBM comment number 221 Page=393 Subtype=Highlight Author=George Penokie Comment= 9.2.2.5.4 RESPONSE information unit SENSE_DATA format This << need not >> should be changed to << is not required to >> IBM comment number 222 Page=399 Subtype=Highlight Author=George Penokie Comment= 9.2.4.6 RESPONSE frame - handling of link layer errors This << machine retransmits the RESPONSE frame at least one time with the RETRANSMIT bit set to zero >> should be << machine retransmits the RESPONSE frame atleast one time with the RETRANSMIT bit set to one >> IBM comment number 223 Page=399 Subtype=Highlight Author=George Penokie Comment= 9.2.4.6 RESPONSE frame - handling of link layer errors This << same I_T_L_Q nexus, the ST_TFR state machine discards the extra RESPONSE frame (see 9.2.6.3.2). >> should be << same I_T_L_Q nexus, the ST_IFR state machine discards the extra RESPONSE frame (see x.x.x.x). >> IBM comment number 224 Page=399 Subtype=Text Author=George Penokie Comment= 9.2.5.2 SSP initiator port error handling summary Add a then to all the if statements so they all read <> IBM comment number 225 Page=399 Subtype=Highlight Author=George Penokie Comment= 9.2.4.6 RESPONSE frame - handling of link layer errors This << If the ST_TFR state machine and the ST_TTS state machine not previously received the RESPONSE frame, they considers the RESPONSE frame to be the valid RESPONSE frame. >> needs help how about << If the ST_IFR state machine has not previously received the RESPONSE frame, the ST_IFR should consider the RESPONSE frame to be the valid RESPONSE frame. >> IBM comment number 226 Page=400 Subtype=Highlight Author=George Penokie Comment= 9.2.5.3 SSP target port error handling summary This << a TASK frame with a tag that is already in used for a command or another task management function, >> should be << a TASK frame with a tag that is already in use for a command or another task management function, >> IBM comment number 227 Page=400 Subtype=Highlight Author=George Penokie Comment= 9.2.5.2 SSP initiator port error handling summary This << If an SSP initiator port receives a read DATA frame with a data offset that was not expected, the ST_ITS state machine discards that frame and any subsequent read DATA frames received for that command >> would be clearer if changed to << If an SSP initiator port receives a read DATA frame with a data offset that was not expected (see 9.2.6.2.3.7.1), the ST_ITS state machine discards that frame and any subsequent read DATA frames receivedfor that command >> IBM comment number 228 Page=400 Subtype=Highlight Author=George Penokie Comment= 9.2.5.2 SSP initiator port error handling summary This << If an SSP initiator port receives an XFER_RDY frame that is not 12 bytes long, he ST_IFR state machine >> should be << If an SSP initiator port receives an XFER_RDY frame that is not 12 bytes long, the ST_IFR state machine >> IBM comment number 229 Page=400 Subtype=Text Author=George Penokie Comment= 9.2.5.3 SSP target port error handling summary Add a then to all the if statements so they all read <> IBM comment number 230 Page=400 Subtype=Highlight Author=George Penokie Comment= 9.2.5.3 SSP target port error handling summary This << the ST_TFR state machine may process this as an I_T nexus >> should be << then, the ST_TFR state machine may process this as an I_T nexus >> IBM comment number 231 Page=400 Subtype=Highlight Author=George Penokie Comment= 9.2.5.3 SSP target port error handling summary This << the ST_TTS state machine returns a RESPONSE frame with the DATAPRES>> should be << then, the ST_TTS state machine returns a RESPONSE frame with the DATAPRES>> IBM comment number 232 Page=401 Subtype=Text Author=George Penokie Comment= 9.2.6 ST (transport layer for SSP ports) state machines During review of SAS 1.1 transport layer state machine descriptions it became apparent that the frame level retry description in the state machines was not complete and that the states in state machines that contained more than one state were not passing arguments. There appeared to be an assumptionthat a state would always have the information it wanted without regardas to where the information came from. This proposal 05-143 addressesboth those problems. The comments included with these comments, for the most part, are not included in 05-143 and should be treated as independent of 05-143. IBM comment number 233 Page=401 Subtype=Square Author=George Penokie Comment= 9.2.6.1 ST state machines overview Remove the << the >> from all the items in the a.b.c list. The items should read as <> should be << b) Frame Received. The confirmations include the following as arguments: >> IBM comment number 235 Page=403 Subtype=Text Author=George Penokie Comment= 9.2.6.2.1 ST_I state machines overview What happens if a cancel message is sent to the ST_ITS6 state if the state machine is in the ST_ITS7 state. Under the current description it would be missed. Is that OK? IBM comment number 236 Page=403 Subtype=Text Author=George Penokie Comment= 9.2.6.2.1 ST_I state machines overview What happens if a cancel message is sent to the ST_ITS2 state if the state machine is in the ST_ITS3, ST_ITS4, or ST_ITS5 states. Under the current description it would be missed. Is that OK? IBM comment number 237 Page=403 Subtype=Square Author=George Penokie Comment= 9.2.6.2.1 ST_I state machines overview Figure 168 The background around the << HARD_RESET Received (to all state machines) >> confirmation should be changed from white to none. IBM comment number 238 Page=405 Subtype=Highlight Author=George Penokie Comment= 9.2.6.2.2 ST_IFR (initiator frame router) state machine This << If the frame type is XFER_RDY then this state machine shall check the lengthof the information unit. If the length of the information unit is not correct, then this state machine shall discard the frame >> needs to have a << Service Delivery or Target Failure - XFER_RDY xxxxx to the SCSI application layer >> added as the description in section 9.2.5.2 states << If an SSP initiator port receives an XFER_RDY frame that is not 12 bytes long, he ST_IFR state machine discards the frame (see 8.2.6.2.2). The application client may then abort the command (see 10.2.2).>>. Without the added words there is no confirmation to the application layer that an abort should occur. IBM comment number 239 Page=405 Subtype=Highlight Author=George Penokie Comment= 9.2.6.2.2 ST_IFR (initiator frame router) state machine This << a) the retry data frames bit; b) the retransmit bit; c) the target porttransfer tag; and d) the information unit. >> should be << a) retry data frames bit; b) retransmit bit; c) target port transfer tag; and d) information unit. >> IBM comment number 240 Page=407 Subtype=Text Author=George Penokie Comment= 9.2.6.2.3.3.1 State description The 2nd paragraph tells what to do it the number of retrys for a COMMAND has not been reached but there is nothing that states what to do if the number of retrys for a COMMAND has been reached. This needs to be fixed. IBM comment number 241 Page=409 Subtype=Highlight Author=George Penokie Comment= 9.2.6.2.3.3.1 State description Table 121 This << (ACK Received >> should be << (ACK Received) >> IBM comment number 242 Page=410 Subtype=Highlight Author=George Penokie Comment= 9.2.6.2.3.3.1 State description This is in 05-143. This << If this state machine receives an XFER_RDY Arrived message and the requested offset is not expected, >> was carried over from SAS and looks like it needs more clerification now that retries are allowed. It should be changed to <> IBM comment number 243 Page=410 Subtype=Highlight Author=George Penokie Comment= 9.2.6.2.3.3.1 State description This << ST_IPR state machine. >> should be << ST_IFR state machine. >> IBM comment number 244 Page=410 Subtype=Highlight Author=George Penokie Comment= 9.2.6.2.3.3.1 State description This << ST_IPR state machine. >> should be << ST_IFR state machine. >> IBM comment number 245 Page=410 Subtype=Highlight Author=George Penokie Comment= 9.2.6.2.3.3.5 Transition ST_ITS2:Initiator_Send_Frame to ST_ITS5:Prepare_Data_Out This << NOTE 52 - This transition occurs even if this state has not received a Transmission Status (ACK Received) for the COMMAND frame for the write operation. >> should be moved to after item a) IBM comment number 246 Page=410 Subtype=Highlight Author=George Penokie Comment= 9.2.6.2.3.3.1 State description This << a) the destination SAS address; and b) the tag. >> should be << a) destination SAS address; and b) tag. >> IBM comment number 247 Page=412 Subtype=Text Author=George Penokie Comment= 9.2.6.2.3.7.1 State description The 1,2,3 list does not look like is requires order. Change to an a,b,c list. IBM comment number 248 Page=412 Subtype=Highlight Author=George Penokie Comment= 9.2.6.2.3.6.1 State description This << j) DATA OFFSET field set to the specified data offset, unless otherwise specified in this subclause; and k) in the information unit, DATA field set to the specified data. l) fill bytes, if any. >> should be << j) DATA OFFSET field set to the specified data offset, unless otherwise specified in this subclause; k) in the information unit, DATA field set to the specified data; and l) fill bytes, if any. >>. The << and >> is on the wrong item. IBM comment number 249 Page=415 Subtype=Square Author=George Penokie Comment= 9.2.6.3.1 ST_T state machines overview Figure 169 The background around the << HARD_RESET Received (to all state machines) >> confirmation should be changed from white to none. IBM comment number 250 Page=419 Subtype=Text Author=George Penokie Comment= 9.2.6.3.2 ST_TFR (target frame router) state machine Having all this space between the start of a sentence and the end of the sentence is not a good idea. Move the table anchor to it's own paragraph and this willnot be a problem. IBM comment number 251 Page=422 Subtype=Highlight Author=George Penokie Comment= 9.2.6.3.3.3.1 State description This << a) the tag; and b) the arguments received with the Transmission Status confirmation. >> should be << a) tag; and b) arguments received with the Transmission Status confirmation. >> IBM comment number 252 Page=422 Subtype=Highlight Author=George Penokie Comment= 9.2.6.3.3.3.1 State description This note << NOTE 55 - The XFER_RDY and RESPONSE frame rules ensure that wide ports do not send an XFER_RDY orRESPONSE frame on a phy until all the ACKs have been transmitted for write DATA frames on a different phy. In a narrow port, the link layer ensures that ACK/NAKs are balanced before transmitting an interlocked frame. >> is the wrong font size. It should be 9 point. IBM comment number 253 Page=423 Subtype=Square Author=George Penokie Comment= 9.2.6.3.3.3.1 State description Table 125 row three This << a) the Transmit Frame request was for a RESPONSE frame; and b) the vendor-specific number of retries has been reached >> should be << The Transmit Frame request was for a RESPONSE frame and the vendor-specific number of retries has been reached. >> IBM comment number 254 Page=423 Subtype=Square Author=George Penokie Comment= 9.2.6.3.3.3.1 State description Table 125 row three This << a) the Transmit Frame request was for a read DATA frame; b) the number of databytes transmitted equal the request byte count; and c) this state hasreceived a Transmission Status (ACK Received) confirmation for each read DATA frame transmitted for the request >> should be << The Transmit Frame request was for a read DATA frame and: a) the number of data bytes transmitted equal the request byte count; and b) this state has received a Transmission Status (ACK Received) confirmation for each read DATA frame transmitted for the request. IBM comment number 255 Page=423 Subtype=Highlight Author=George Penokie Comment= 9.2.6.3.3.3.1 State description Table 125 Delete all the <> from the beginning of each entry in the middle column. It adds nothing and has the benefit of not having to argue about if the <> should be capitalized or not. IBM comment number 256 Page=424 Subtype=Highlight Author=George Penokie Comment= 9.2.6.3.3.3.1 State description Again, this << a) the destination SAS address; and b) the tag. >> should be << a) destination SAS address; and b) tag. >> IBM comment number 257 Page=424 Subtype=Highlight Author=George Penokie Comment= 9.2.6.3.3.3.1 State description This << a) the destination SAS address; and b) the tag. >> should be << a) destination SAS address; and b) tag. >> IBM comment number 258 Page=425 Subtype=Text Author=kdbutt Comment= 9.2.6.3.3.4.1 State description In looking at the error recovery, I have noticed a few inconsistencies in the document. It appears that when sections 9.2.4 and 9.2.5 were added, the state diagrams were not updatedto match. Proposal 05-143 contains the fixes for this problem. 9.2.6.3.3.5.1 states: i) TARGET PORT TRANSFER TAG field set to a vendor-specific value, unless otherwise specified in this subclause; and If this state is entered after the ST_TTS2:Target_Send_Frame state received a Transmission Status (Frame Transmitted) confirmation and a confirmation other than Transmission Status (ACK Received) for which a Transmission Complete message was not sent to the ST_TFRstate machine (i.e., to retry transmitting a frame), then this state shall construct a new XFER_RDY frame using the values from the previous XFER_RDY frame except: a) the RETRANSMIT bit shallbe set to one; and b) the value in the TARGET PORT TRANSFER TAGfield shall be set to a different value than the value in the previous XFER_RDY frame. The new target port transfer tag value shallnot conflict with any other target port transfer tag currently in use. If write data is received for a subsequent XFER_RDY frame for a command, then all target port transfer tags used for previous XFER_RDY frames for the command are no longer in use. but the above does not match with 9.2.4.1 states: If the TRANSPORT LAYER RETRIES bit is set to one, the logical unit: d) selects a different value for the TARGET PORT TRANSFER TAG field in each XFER_RDY frame than that used in the previous XFER_RDY frame for that I_T_L_Q nexus; IBM comment number 259 Page=425 Subtype=Highlight Author=George Penokie Comment= 9.2.6.3.3.4.1 State description This << j) DATA OFFSET field set as specified in this subclause; and >> should be << j) DATA OFFSET field set as specified in this subclause; >> IBM comment number 260 Page=426 Subtype=Text Author=kdbutt Comment= 9.2.6.3.3.6.1 State description In looking at the error recovery, I have noticed a few inconsistencies in the document. It appears that when sections 9.2.4 and 9.2.5 were added, the state diagrams were not updated to match. Proposal 05-143 contains the fixes for this problem. 9.2.6.3.3.6.1 states: 1) If the data offset was not expected (i.e.,the CHANGING DATA POINTER bit is set to one and the value in the DATA OFFSET field is not set to the data offset associated with the XFER_RDY frame, or the CHANGING DATA POINTER bit is set to zero and the value in the DATA OFFSET field is not set to the value in the DATA OFFSET FIELD in the previous write DATA information unit plus the number of bytes in that information unit), then thisstate shall send a Reception Complete (Data Offset Error) message to the ST_TFR state machine; and then 9.2.6.3.2 table 124 states that Reception Complete (Data Offset Error) translates to aSCSI application layer: Data-Out Received with the Delivery Result argument set to DELIVERY FAILURE - DATA OFFSET ERROR Which will prohibit any recovery. So, if recovery is possible, then 9.2.6.3.3.6.1 cannot send the Reception Complete (Data Offset Error) message until recovery has been exhausted. However, 9.2.6.3.3.6.1 does not mention recovery at all. IBM comment number 261 Page=426 Subtype=Square Author=George Penokie Comment= 9.2.6.3.3.6.1 State description The 1,2,3 list does not appear to require ordering so it should be changed to an a,b,c list. IBM comment number 262 Page=426 Subtype=Highlight Author=George Penokie Comment= 9.2.6.3.3.5.1 State description This << j) DATA OFFSET field set to zero; and >> should be << j) DATA OFFSET field set to zero; >> IBM comment number 263 Page=427 Subtype=Highlight Author=George Penokie Comment= 9.2.6.3.3.8.1 State description This << h) TARGET PORT TRANSFER TAG field set to zero; >> should be << h) TARGET PORT TRANSFER TAG field set to zero; and>> IBM comment number 264 Page=427 Subtype=Highlight Author=George Penokie Comment= 9.2.6.3.3.7.1 State description This << This state shall process the data received in the Data-Out Arrived message using the Device Server Buffer (e.g., logical block address) to which the data is to be transferred. >> should be << This state shall process the SSP frame contents using the Device Server Buffer (e.g., logical block address) to which thedata is to be transferred. >> IBM comment number 265 Page=427 Subtype=Highlight Author=George Penokie Comment= 9.2.6.3.3.7.2 Transition ST_TTS6:Process_Data_Out to ST_TTS5:Receive_Data_Out This << state has processed the data received in a Data-Out Arrived message.>> should be << has processed the SSP frame contents. >> IBM comment number 266 Page=430 Subtype=Highlight Author=George Penokie Comment= 9.4.3 SMP_RESPONSE frame This << frame 1 032 bytes (1 024 bytes of data + 4 bytes of header + 4 bytes of CRC). >> should be << frame 1 032bytes (i.e., 1 024 bytes of data + 4 bytes of header + 4 bytes of CRC). IBM comment number 267 Page=430 Subtype=Highlight Author=George Penokie Comment= 9.4.2 SMP_REQUEST frame This << frame 1 032 bytes (1 024 bytes of data + 4 bytes of header + 4 bytes of CRC). >> should be << frame 1 032 bytes (i.e., 1 024 bytes of data + 4 bytes of header + 4 bytes of CRC). IBM comment number 268 Page=438 Subtype=Highlight Author=George Penokie Comment= 10.2.1.3 SCSI Command Received transport protocol service This << SCSI Command Received (IN (I_T_L_Q Nexus, CDB, Task Attribute, [Task Priority], [Command Reference Number])) >> should be << SCSI Command Received (IN (I_T_L_Q Nexus, CDB, Task Attribute, [Task Priority], [Command Reference Number], [First Burst Enabled])) >> IBM comment number 269 Page=447 Subtype=Highlight Author=George Penokie Comment= 10.2.2 Application client error handling This << it shall abort the command (e.g., by sending an ABORT TASK task management function). >> should be << then the SSP initiator port shall abort the command (e.g., by sending an ABORT TASK task management function). >> IBM comment number 270 Page=448 Subtype=Highlight Author=George Penokie Comment= 10.2.3 Device server error handling This << If the SCSI target device performs tag checking and an SSP target port calls SCSI Command Received() with a tag already in use by another SCSI command (i.e., an overlapped command) in any logical unit, the task router and device server(s) shall abort all task management functions received on that I_T nexusand shall respond to the overlapped command as defined in SAM-3. >> should be changed to << If the SCSI target device performs tag checking andan SSP target port calls SCSI Command Received () with a tag already in use by another SCSI command (i.e., an overlapped command) in any logical unit, the task router and device server(s) shall respond to the overlapped command as defined in SAM-3. >> as there are more specific rules on aborting below in the second a.b.c list in section 10.2.4. IBM comment number 271 Page=449 Subtype=Text Author=George Penokie Comment= 10.2.7.1.1 Disconnect-Reconnect mode page overview Having all this space between the start of a sentence and the end of the sentence is not a good idea. Move the table anchor to it's own paragraph and this will notbe a problem. IBM comment number 272 Page=451 Subtype=Highlight Author=George Penokie Comment= 10.2.7.1.4 MAXIMUM BURST SIZE field This << the SSP target port shall prepare to close the connection after the amount of data specified by the MAXIMUM >> should be << then, the SSP target port shall prepare to close the connection after the amount of data specified by the MAXIMUM >> IBM comment number 273 Page=453 Subtype=Highlight Author=George Penokie Comment= 10.2.7.2.2 Protocol-Specific Port mode page - short format This << SPF field shall >> should be << SPF bit shall >> IBM comment number 274 Page=454 Subtype=Highlight Author=George Penokie Comment= 10.2.7.2.3 Protocol-Specific Port mode page - Phy Control And Discover subpage This << A SAS phy mode descriptor shall be included for each phy in the SAS target device (not just the SAS target port), starting with the lowest numbered phy and ending with the highest numbered phy. >> should be << A SAS phy mode descriptor shall be included for each phy inthe SAS target device, not just the SAS target port, starting with the lowest numbered phy and ending with the highest numbered phy. >> IBM comment number 275 Page=454 Subtype=Highlight Author=George Penokie Comment= 10.2.7.2.3 Protocol-Specific Port mode page - Phy Control And Discover subpage This << SPF field shall >> should be << SPF bit shall >> IBM comment number 276 Page=456 Subtype=Highlight Author=George Penokie Comment= 10.2.7.3.2 Protocol-Specific Logical Unit mode page - short format This << SPF field shall >> should be << SPF bit shall >> IBM comment number 277 Page=458 Subtype=Highlight Author=George Penokie Comment= 10.2.8.1 Protocol-Specific log page This << control bits for >> should be << control bits and fields for >> as TMC is a field not a bit. IBM comment number 278 Page=458 Subtype=Highlight Author=George Penokie Comment= 10.2.8.1 Protocol-Specific log page This << control bits for >> should be << control bits and fields for >> as TMC is a field not a bit. IBM comment number 279 Page=460 Subtype=Text Author=George Penokie Comment= 10.2.9.1 Protocol-Specific diagnostic page Having all this space between the start of a sentence and the end of the sentence is not a good idea. Move the table anchor to it's own paragraph and this will not be a problem. IBM comment number 280 Page=462 Subtype=Highlight Author=George Penokie Comment= 10.2.10.2.1 SA_PC state machine overview This << This state machine stall start in the SA_PC_0:Powered_On state after power on. >> should be << This state machine shall start in the SA_PC_0:Powered_On state after power on. >> IBM comment number 281 Page=462 Subtype=Highlight Author=George Penokie Comment= 10.2.10.1 SCSI power conditions overview This << a) automatically spin-up after power on; and >> should be << a) initiate spin-up after power on; and >> IBM comment number 282 Page=467 Subtype=Square Author=George Penokie Comment= 10.2.11 SCSI vital product data (VPD) table 165 This <> should be << PIV (protocol identifier valid) >> IBM comment number 283 Page=472 Subtype=Highlight Author=George Penokie Comment= 10.4.3.1 SMP function request frame format This << size of the frame 1 032 bytes (1 024 bytes of data + 4 bytes of header + 4 bytes of CRC).>> should be << size of the frame 1 032 bytes (i.e., 1 024 bytes of data + 4 bytes of header + 4 bytes of CRC). >> IBM comment number 284 Page=473 Subtype=Square Author=George Penokie Comment= 10.4.3.2 SMP function response frame format table 170 This << The SMP target port does not support the requested SMP function; the ADDITIONALRESPONSE BYTES field may be present but shall be ignored. >> should be << The SMP target port does not support the requested SMP function. The ADDITIONAL RESPONSE BYTES field may be present but shall be ignored. >> IBM comment number 285 Page=473 Subtype=Square Author=George Penokie Comment= 10.4.3.2 SMP function response frame format table 170 This <> should be << The SMP target port supports the SMP function. The ADDITIONAL RESPONSE BYTES field contains the requested information. >> IBM comment number 286 Page=474 Subtype=Highlight Author=George Penokie Comment= 10.4.3.2 SMP function response frame format This << size of the frame 1 032 bytes (1 024 bytes of data + 4 bytes of header + 4 bytes of CRC). >> should be << size of the frame 1 032 bytes (i.e., 1 024 bytes of data + 4 bytes of header + 4 bytes of CRC). >> IBM comment number 287 Page=476 Subtype=Highlight Author=George Penokie Comment= 10.4.3.3 REPORT GENERAL function This << need not >> should be changed to << is not required to >> IBM comment number 288 Page=482 Subtype=Text Author=George Penokie Comment= 10.4.3.5 DISCOVER function Having all this space between the start of a sentence and the end of the sentence is not a good idea. Move the table anchor to it's own paragraph and this will not be a problem. IBM comment number 289 Page=484 Subtype=Highlight Author=George Penokie Comment= 10.4.3.5 DISCOVER function This << NOTE 62 - Supports for SATA hosts is outside the scope of this standard. >> should be << NOTE 62 - Support for SATA hosts is outside the scope of this standard. >> IBM comment number 290 Page=485 Subtype=Highlight Author=George Penokie Comment= 10.4.3.5 DISCOVER function This makes no sense << c) the phy identifier provided for the attached port if the attached port is a SATA deviceport. >> If should be << c) the phy identifier provided for the attached phy if the attached phy is contained in a SATA device port. >> IBM comment number 291 Page=485 Subtype=Highlight Author=George Penokie Comment= 10.4.3.5 DISCOVER function This makes no sense << b) the phy identifier of the attached expander device if the attached port is an expander port; >> It should be << b) the phy identifier of the attached phy if the attached phy is contained in an expander port; >> IBM comment number 292 Page=485 Subtype=Highlight Author=George Penokie Comment= 10.4.3.5 DISCOVER function This makes no sense << a) the phy identifier of the attached SAS port if the attached port is a SAS port; >>. It should be << a) the phy identifier of the attached phy if the attached phy is contained in a SAS port; >> IBM comment number 293 Page=486 Subtype=Highlight Author=George Penokie Comment= 10.4.3.5 DISCOVER function This << need not >> should be changed to << is not required to >> IBM comment number 294 Page=488 Subtype=Text Author=George Penokie Comment= 10.4.3.6 REPORT PHY ERROR LOG function It appears that the counters defined in the log function are never reset to zero. This does not seem like a good idea. At a minimum there should be a statement that the counters are all reset on a power on. IBM comment number 295 Page=492 Subtype=Highlight Author=George Penokie Comment= 10.4.3.8 REPORT ROUTE INFORMATION function This << The EXPANDER ROUTE INDEX field specifies the expander route index for the expander route entry being requested (see 4.6.7.3). >> should be << The EXPANDER ROUTE INDEX field specifies the expander route index for the expander route entry (see 4.6.7.3) of the phy indicated in the PHY IDENTIFIER field. >> IBM comment number 296 Page=493 Subtype=Highlight Author=George Penokie Comment= 10.4.3.8 REPORT ROUTE INFORMATION function This << The EXPANDER ROUTE INDEX field contains the expander route index for the expander route entry being returned (see 4.6.7.3). >> should be << The EXPANDER ROUTE INDEX field contains the expander route index for the expander route entry(see 4.6.7.3) of the phy indicated in the PHY IDENTIFIER field. >> IBM comment number 297 Page=495 Subtype=Highlight Author=George Penokie Comment= 10.4.3.9 CONFIGURE ROUTE INFORMATION function This << The EXPANDER ROUTE INDEX field specifies the expander route index for the expander routeentry being configured (see 4.6.7.3). >> should be << The EXPANDER ROUTE INDEX field specifies the expander route index for the expander route entry (see 4.6.7.3) of the phy indicated in the PHY IDENTIFIER field. >> IBM comment number 298 Page=499 Subtype=Highlight Author=George Penokie Comment= 10.4.3.10 PHY CONTROL function This paragraph << If the PHY IDENTIFIER field specifies the phy which is being used for the SMP connection and a phy operation of LINK RESET, HARD RESET, or DISABLE is requested, the SMP target port shall not perform the requested operation and shall return a function result of SMP FUNCTION FAILED in the response frame. >> should be moved up to the PHY IDENTIFIER field description. IBM comment number 299 Page=500 Subtype=Highlight Author=George Penokie Comment= 10.4.3.10 PHY CONTROL function This << in the response frame. If it does so, it shall not perform the requested phy operation. >> should be <> IBM comment number 300 Page=502 Subtype=Text Author=George Penokie Comment= 10.4.3.11 PHY TEST FUNCTION function The PHY TEST FUNCTION is description is a duplicate of the description in the protocol-specific diagnostic page. The description here should be replaced with a reference to thatdescription. IBM comment number 301 Page=506 Subtype=Square Author=George Penokie Comment= A.2 Compliant jitter tolerance pattern (CJTPAT) I believe the a,b,c list should be ordered. Change it to a 1,2,3 list. IBM comment number 302 Page=520 Subtype=Highlight Author=George Penokie Comment= B.9.3 Use of single-ended instrumentation in differential applications This << denoted by the \217A' subscript and reflected signals from the same port denoted by the \217B' subscript. >> should be << denoted by the A subscript and reflected signals from the same port denoted by the B subscript. >> IBM comment number 303 Page=520 Subtype=Highlight Author=George Penokie Comment= B.9.3 Use of single-ended instrumentation in differential applications This << d) SCCij.. common-mode stimulus, >> should be << d) SCCij: common-mode stimulus, >> IBM comment number 304 Page=521 Subtype=Highlight Author=George Penokie Comment= B.9.3 Use of single-ended instrumentation in differential applications This << VNA ports are all single-ended; the differential and common-mode properties for differential ports are >> should be << VNA ports are all single-ended. The differential and common-mode properties for differential ports are >> IBM comment number 305 Page=532 Subtype=Highlight Author=George Penokie Comment= E.2 Hash collision probability This << One randomly chosen SAS address (representing a replacement unit) with another unique >> should be <> IBM comment number 306 Page=532 Subtype=Highlight Author=George Penokie Comment= E.2 Hash collision probability This << One randomly chosen SAS address (representing a replacement unit) with another unique >> should be <> IBM comment number 307 Page=532 Subtype=Highlight Author=George Penokie Comment= E.2 Hash collision probability This << each lot were assigned by 10 SAS address-writers, randomly drawn from a pool of 4 096 possible >> should be << each lot were assigned by ten SAS address-writers, randomly drawn from a pool of 4 096 possible >> IBM comment number 308 Page=532 Subtype=Highlight Author=George Penokie Comment= E.2 Hash collision probability This << within the lot were assigned by 10 SAS address-writers, randomly drawn from a pool of 4 096 >> should be << within the lot were assigned by ten SAS address-writers, randomly drawn from a pool of 4 096 >> IBM comment number 309 Page=541 Subtype=Highlight Author=George Penokie Comment= G.3.1 Affiliation policies overview This << connection to send a command (perhaps a read), and >> should be << connection to send a command(e.g., a read), and >> ************************************************************** Comments attached to No ballot from Robert Sheffield of Intel Corp.: INTEL #1 PDF Page: 48 Author: Bob Sheffield Comment: 3.1.35 cumulative distribution function (CDF): This may not be the correct definition - even as it applies to jitter measurements. It is not cumulative over time, but rather cumulative over a population of jitter measurement samples. Jitter samples are measured as intervals of time, but this definition sounds like it's based on absolute time, not sampled intervals. Suggest: "The integral of the PDF (see 3.1.143) with limits from negative infinity to a specified jitter value, or from a specified jitter value to positive infinity." INTEL #2 PDF Page: 54 Author: Bill Bissonette Comment: 3.1 Definitions, symbols, abbreviations: Add definition for 'probe point'. Could read something like, "Physical positions in the test load where the signal properties are measured. See Section 5.3.2.1." INTEL #3 PDF Page: 119 Author: Bob Sheffield Comment: 4.6.6.5 BPP interface - Table 15 Third Row (Identification Sequence Complete): "or because a virtual phy has been enabled (see 10.4.3.10)." s/b " because an STP/SATA bridge received the initial Register - Device to Host FIS (see 7.9.5.5.3 and 9.3.1), or because a virtual phy has been enabled (see 10.4.3.10)." INTEL #4 PDF Page: 123 Author: Bob Sheffield Comment: 4.7.2 Allowed topologies Fifth paragraph: This doesn't say what's intended. If the port of the expander device being configured is a subtractive decode port, and the expander device attached to that port has two or more ports with table-routing phys attached to other expanders, then the management application will find the SAS address of the port being configured in the ports of the other expander devices which connect to the same expander device, but it is not a routing loop. INTEL #5 PDF Page: 124 Author: Bob Sheffield Comment: There is no place in the standard that specifies when (if ever) the ATTACHED SAS ADDRESS is set to zero. There probably should be (perhaps on any transition to SP0:OOB_COMINIT?). INTEL #6 PDF Page: 132 Author: Mark Seidel Comment: 5.1 Physical overview 4th line: "reference" => "references" INTEL #7 PDF Page: 132 Author: Bill Bissonette Comment: 5.2 Passive interconnect: Figures 50 through 56 -- Arrows between plugs and receptacles imply conductor length. These should all be removed and plugs/receptacles show as mated. INTEL #8 PDF Page: 134 Author: Bill Bissonette Comment: 5.2.2 SAS cables and connectors: Figures 52 through 56 -- Title embedded in Figure is redundant to figure title. Recommend removing. INTEL #9 PDF Page: 141 Author: Schelto VanDoorn Comment: 5.2.3.3.2 SAS external cable plug connector - Figure 61 „ SAS external cable plug connector Need: to define the location of pin 1 (S1). Draw picture showing pinning. INTEL #10 PDF Page: 142 Author: Schelto VanDoorn Comment: 5.2.3.3.3 SAS external receptacle connector - Figure 62 - SAS external receptacle connector: Need to define the location of pin 1 (S1). Draw picture showing pinning. INTEL #11 PDF Page: 142 Author: Bill Bissonette Comment: 5.2.3.3.3 SAS external receptacle connector, text immediately below figure 62: Grammar -- "are" should be "is". INTEL #12 PDF Page: 145 Author: Bob Sheffield Comment: 5.2.3.3.6 SAS external compact receptacle connector Last paragraph (after Figure 64): "are" s/b "is" INTEL #13 PDF Page: 154 Author: Bill Bissonette Comment: 5.2.3.4.7 SAS internal compact wide connector pin assignments - Table 28 „ Controller SAS ...: Rows should be organized (ordered) like Table 25 -- External Wide Compact INTEL #14 PDF Page: 154 Author: Bill Bissonette Comment: 5.2.3.4.7 SAS internal compact wide connector pin assignments - Table 28 „ Controller SAS ...: TX+, TX- are swapped (known issue). This will cause interconnect pinout definition to change (for the better). INTEL #15 PDF Page: 155 Author: Bill Bissonette Comment: 5.2.3.4.7 SAS internal compact wide connector pin assignments - Table 29 „ Backplane SAS internal compact...: Rows should be organized like Table 25. INTEL #16 PDF Page: 157 Author: Bill Bissonette Comment: 5.2.4.1 SAS internal cables, figure 72, 73: Should be "RX" and "TX" (vs. "RP" AND "TP") on host connector since there is no primary or secondary designations on host side. This may apply to target connector as well since only one port used. INTEL #17 PDF Page: 162 Author: Bill Bissonette Comment: 5.2.4.3.2 SAS internal wide symmetric cables - Figure 76 „ SAS internal wide cable...: Pin order on both connectors (A1, B1, A2, B2, . . . ) will be the same once the TX+/TX- pin assignments gets fixed. This figure must be updated to reflect that. INTEL #18 PDF Page: 163 Author: Bill Bissonette Comment: 5.2.4.3.1 SAS internal wide cables overview, figure 77: This figure is not correct: Signal/pin assignments on both connectors must be the same (controller version of pinout) and RX0 lane attaches to TX3 lane, etc. Pin sequence on right-hand connector should be changed to sequence used on left hand connector (only from top to bottom). Once TX signal polarities get fixed, the interconnect lines will straighten out. Should look like the wide 4x internal connector (controller to controller) Tx0<->Rx3, Tx1<->Rx2,.... INTEL #19 PDF Page: 164 Author: Bill Bissonette Comment: 5.2.4.3.1 SAS internal wide cables overview, figure 78: "RP"s and "TP"s should be "RX"s and "TX"s since there is no primary/secondary designation here. INTEL #20 PDF Page: 165 Author: Bill Bissonette Comment: 5.2.4.3.1 SAS internal wide cables overview, figure 79, 81: This figure needs to be corrected once TX+/TX- signal/pin assignments get straightened out. INTEL #21 PDF Page: 167 Author: Bill Bissonette Comment: 5.2.4.3.1 SAS internal wide cables overview, Figure 81: Pin sequence should match physical layout (like in Figure 79). Will have better symmetry when the [RT]+/[RT]- gets fixed. INTEL #22 PDF Page: 170 Author: Bob Sheffield Comment: 5.2.5 Backplanes Table 30: Column heading: Delete the 1.5 Gbps column. The assumption is that all cables/connectors/backplanes are 3G capable, and so must pass the 3G spec. Applies to tables 31 & 32 as well INTEL #23 PDF Page: 170 Author: Bill Bissonette Comment: 5.2.6 Impedance and media specifications, table 30, 31, 32: Table title says 'media requirements', but implication from note 'b' is that "Maximum TDR rise time" row is a requirement for measurement procedure. These specs should be reflected in notes and this row removed. Table footnotes a,b,c and d should all go with the "Requirement" column heading". Only table footnote 'e' doesn't apply to all rows. INTEL #24 PDF Page: 172 Author: Bob Sheffield Comment: 5.3.1 Compliance points First paragraph: Delete, "that contain or comprise the candidate compliance point" INTEL #25 PDF Page: 172 Author: Bob Sheffield Comment: 5.3.1 Compliance points Second paragraph: "Signal compliance is measured at physical positions denoted as probe points inside a test load (see 5.3.2)." s/b "Signal compliance is measured at physical positions in a test load that approximate compliance points defined in a functional configuration (see 5.3.2)." Note: This paragraph should concisely define the relationship between a compliance point and a probe point (making it clear that a measurement made at a probe point constitutes an acceptable value to compare against the compliance values called out in the tables. Subsequently, probe points should be discussed in reference to figures to show measurements points, but not discussed in relation to the tables which specify the compliance values. INTEL #26 PDF Page: 185 Author: Bob Sheffield Comment: 5.3.3 General electrical characteristics - fourth paragraph: "exceed" s/b "exhibit a BER less than" INTEL #27 PDF Page: 188 Author: Bill Bissonette Comment: 5.3.5 Electrical TxRx connections First paragraph: "connection individual" s/b "connection, individual" INTEL #28 PDF Page: 188 Author: Bill Bissonette Comment: 5.3.5 Electrical TxRx connections - first paragraph, second line: "materials, including" s/b "materials including" INTEL #29 PDF Page: 192 Author: Bob Sheffield Comment: 5.3.7.2, Table 37, 38, 39, 40 (parts 1 and 2), 41, 42: delete "at probe point" INTEL #30 PDF Page: 193 Author: Bill Bissonette Comment: 5.3.7.3, Table 38 Table footnote (g): SATA does not allow 3,0 Gbps aligns in OOB. It DOES allow 1.5 Gbps OOB w/ 3,0 Gbps edge rates. Delete ", or 3.0 Gbps ALIGN (0) dwords" INTEL #31 PDF Page: 193 Author: Bob Sheffield Comment: 5.3.7.2, Table 37, 38, 39, 40 (parts 1 and 2), 41, 42: delete "at probe point" INTEL #32 PDF Page: 193 Author: Bob Sheffield Comment: Table 38 „ Transmitter device signal output characteristics...: Delete "as measured with each test load". It should be made clear this applies to all measurements in subclause 5.3.1 and not reiterated here. INTEL #33 PDF Page: 194 Author: Bob Sheffield Comment: Table 39 „ Transmitter device maximum jitter...: Delete "as measured with each test load". It should be made clear this applies to all measurements in subclause 5.3.1 and not reiterated here. INTEL #34 PDF Page: 194 Author: Bob Sheffield Comment: 5.3.7.2, Table 37, 38, 39, 40 (parts 1 and 2), 41, 42: delete "at probe point" INTEL #35 PDF Page: 195 Author: Bob Sheffield Comment: Table 40 „ Delivered signal characteristics...: Delete "as measured with the zero-length test load". It should be made clear this applies to all measurements in subclause 5.3.1 and not reiterated here. INTEL #36 PDF Page: 195 Author: Bob Sheffield Comment: 5.3.7.2, Table 37, 38, 39, 40 (parts 1 and 2), 41, 42: delete "at probe point" INTEL #37 PDF Page: 196 Author: Bob Sheffield Comment: Table 40 „ Delivered signal characteristics...: Delete "as measured with the zero length test load". INTEL #38 PDF Page: 196 Author: Bill Bissonette Comment: 5.3.8.2 Delivered signal characteristics - Table 40 (part 2 of 2) - table footnote (g): 3 Gpbs OOB not allowed by SATA. Delete ", or 3.0 Gbps ALIGN (0) dwords (see SATA2-PHY)" INTEL #39 PDF Page: 196 Author: Bob Sheffield Comment: 5.3.7.2, Table 37, 38, 39, 40 (parts 1 and 2), 41, 42: delete "at probe point" INTEL #40 PDF Page: 197 Author: Bob Sheffield Comment: 5.3.7.2, Table 37, 38, 39, 40 (parts 1 and 2), 41, 42: delete "at probe point" INTEL #41 PDF Page: 198 Author: Bob Sheffield Comment: 5.3.7.2, Table 37, 38, 39, 40 (parts 1 and 2), 41, 42: delete "at probe point" INTEL #42 PDF Page: 295 Author: Bob Sheffield Comment: 7.9.5.4.3 SL_IR_RIF2:Receive_Identify_Frame state 7.9.5.4.3.1 State description - fifth paragraph: "After receiving an EOAF Received message, this state shall check if it the IDENTIFY address frame is valid." s/b "After receiving an EOAF Received message, this state shall check if the received frame is a valid IDENTIFY address frame." INTEL #43 PDF Page: 296 Author: Bob Sheffield Comment: 7.9.5.5.3 SL_IR_IRC2:Wait state 7.9.5.5.3.1 State description: There is a problem that there is currently no definition for how a phy associated with an STP/SATA bridge becomes enabled. Add the following as the last paragraph: "If this state receives an Initial FIS Received message from the STP transport layer (see 9.3.1) it should send an Enable Disable SAS Link (Enable) message to the XL state machine (see 7.15) in an expander phy indicating that the rest of the link layer may start operation." INTEL #44 PDF Page: 297 Author: Bob Sheffield Comment: 7.11 SAS domain changes: Add the following paragraph after the unordered list: "Expander devices should transmit a BROADCAST (CHANGE) when an STP/SATA bridge receives an initial Register - Device to host FIS (see 9.3.1)." INTEL #45 PDF Page: 400 Author: Bob Sheffield Comment: 9.2.5.2 SSP initiator port error handling summary: Second paragraph Add the following text: An XFER_RDY or RESPONSE frame received with a TAG corresponding to the TAG of a COMMAND or TASK frame which has still not received an ACK, but is otherwise a valid frame, shall be accepted as a valid frame. INTEL #46 PDF Page: 429 Author: Bob Sheffield Comment: 9.3.1 Initial FIS: Add the following text as the second paragraph: "Upon receiving the initial Register - Device to Host FIS, the STP transport layer should send an Initial FIS Received message to the SL_IR state machine (see 7.9.5.5.3). See 7.11 for BROADCAST (CHANGE) requirements related to the initial FIS." INTEL #47 PDF Page: 486 Author: Bob Sheffield Comment: 10.4.3.5 DISCOVER function: In the description of the ATTACHED SAS ADDRESS field, "The ATTACHED SAS ADDRESS field shall be updated:" Insert: "a) when the SP state machine enters the SP0:OOB_COMINIT state (set to zero\;") INTEL #48 PDF Page: 512 Author: Bob Sheffield Comment: Annex B: "(normative)" s/b "(informative)" There are many problems with this being a normative annex: 1) The terms are different. Nowhere is it evident the relationship between CT, CR, IT, and IR compliance points in clause 5 and the Transmit and Receive interoperability points identified in the annex, and what the relationship might be to probe points described in clause-5. 2) Annex B describes a method for "de-embedding" a test fixture, presumably to mitigate the effects of the test load on the compliance measurement. But there is nothing to correlate the compliance values described in clause 5 with specific measurements described in Annex B. The information in Annex B is quality information, but without appropriate changes to correlate the measurement techniques described in Annex B to the compliance values called out in clause 5. I.M.H.O., the bulk of LB comments that would be needed to reconcile the two would constitute a very substantive change, and might represent just cause to hold another LB to resolve. So I recommend making the annex informative for now, and fix it in SAS-2. INTEL #49 PDF Page: 543 Author: Bob Sheffield Comment: Annex G: Add annex G.5 as follows: G.5 Discovery of a SATA device An expander phy with STP/SATA bridge in the SATA Spinup Hold state is indicated in the DISCOVER response NEGOTIATED PHYSICAL LINK RATE field (a value of 3h indicates the phy is enabled and a SATA device has been detected, but it's in the spinup-hold state). An expander device generates a BROADCAST (CHANGE) for the following conditions: a) the phy loses DWS sync and the SP state machine transitions to the SP0:OOB_COMINIT state b) the phy detects the removal or insertion of a SATA port selector c) the phy sequences to the SATA Spinup Hold state d) the phy initialization sequence completes (completes SATA speed negotiation\ e) the phy receives an initial Register - Device to Host FIS. Anytime the SMP management client detects a BROADCAST (CHANGE) from a phy with a STP/SATA bridge, the SMP management client should issue a DISCOVER command to determine the ATTACHED DEVICE TYPE, ATTACHED SAS ADDRESS, and the NEGOTIATED PHYSICAL LINK RATE. If the NEGOTIATED PHYSICAL LINK RATE is 3h, the phy is in the SATA Spinup Hold state, and the SMP management client should issue an SMP PHY CONTROL command with a PHY CONTROL FUNCTION of HARD RESET or LINK RESET to cause link initialization to happen again - this time bypassing the SATA Spinup Hold state. After finding the NEGOTIATED PHYSICAL LINK RATE field set to 8h or 9h (indicating that speed negotiation has completed at 1.5 Gbps or 3.0 Gbps, respectively), the SMP management client may issue the SMP REPORT PHY SATA command to see if there's a signature FIS there yet or not. If the expander doesn't support the SATA SPINUP HOLD state, then the NEGOTIATED PHYSICAL LINK rate field will sequence all the way to 8h or 9h - indicating speed negotiation has completed and the link is ready. The "ATTACHED SATA DEVICE" bit in the DISCOVER response byte 15 indicates if the attached device is a SATA device - determined by having transitioned to the SATA speed negotiation states rather than to the SAS speed negotiation states (which it did because it got a COMSAS timeout). If the initial FIS is not yet present, the SMP management client should wait for the next BROADCAST (CHANGE) from the STP/SATA bridge indicating receipt of the initial FIS, and then reissue the DISCOVER and SMP REPORT PHY SATA command. In some hot-plug cases, a SATA device may not send an initial Register - Device to Host FIS (due to timing where the device does not see the initial COMINIT). In this case the STP/SATA bridge will complete speed negotiation, but will not receive an initial FIS. If this occurs, the SMP management client should time-out after a vendor-specific interval of time and then, after sending a SMP REPORT PHY SATA command that does not report a received initial FIS, the SMP management client should send an SMP PHY CONTROL command specifying a HARD RESET or LINK RESET. This will send a COMINIT to the SATA device, and will cause the SATA device to send the initial Register - Device to Host FIS following link initialization. So - at anytime following the link initialization sequence, it is possible via DISCOVER and REPORT PHY SATA SMP commands to determine: a) If there is a device attached; b) Whether the device is SATA or SAS c) Whether the SP state machine is in the SPINUP HOLD state; d) Whether the SATA device has returned an initial REGISTER DEVICE TO HOST FIS. Using this information, it should be possible for the SMP management client to force the device to transmit the initial FIS if need be through sending an SMP PHY CONTROL command with a function code specifying HARD RESET or LINK RESET. ************************************************************** Comments attached to No ballot from John Lohmeyer of LSI Logic Corp.: LSI comment number 1 Page=32 Subtype=Highlight Author=John Lohmeyer Comment= Revision Information Remove this section prior to public review. LSI comment number 2 Page=36 Subtype=Text Author=John Lohmeyer Comment= Add T10 List to Foreword (available at: http://www.t10.org/ftp/pri/editors/t10-ansi.txt) LSI comment number 3 Page=52 Subtype=Highlight Author=Tim Hoglund Comment= definition does not strictly match 4.1.9 text. Also partial pathway should include case where an OPEN address frame has reached a SAS endpointbut no response has been given (yet). LSI comment number 4 Page=54 Subtype=Highlight Author=Brian Day Comment=This word is not used elsewhere in the spec. Should it be deleted? LSI comment number 5 Page=54 Subtype=Highlight Author=Brian Day Comment=This word is not used elsewhere in the spec. Should it be deleted? LSI comment number 6 Page=78 Subtype=Highlight Author=Tim Hoglund Comment= "same" could imply that port is created when phys receive an identical address to what they transmitted during the identification sequence -- this is misleading. 7.9.1 text is better LSI comment number 7 Page=87 Subtype=Highlight Author=Tim Hoglund Comment=definition needed for "root edge expander device" LSI comment number 8 Page=87 Subtype=Highlight Author=Tim Hoglund Comment= should this statement be an informative note rather than "shall"? clarify "sum of all SAS addresses addressable through the edge expander phymean" LSI comment number 9 Page=90 Subtype=Highlight Author=Tim Hoglund Comment=definition needed for "root edge expander device" LSI comment number 10 Page=91 Subtype=Highlight Author=Tim Hoglund Comment= Text and reference for description of partial pathway not strictly consistent with definition 3.1.131. Also partial pathway should include case whereby OPEN address frame has reached the destination phy but no response has been given (yet). LSI comment number 11 Page=108 Subtype=Highlight Author=Tim Hoglund Comment=remove OPEN_REJECT (WAITING FOR BREAK). see 05-145r0. LSI comment number 12 Page=108 Subtype=Highlight Author=Brian Day Comment=missing "is" LSI comment number 13 Page=110 Subtype=Highlight Author=Tim Hoglund Comment=be more specific, i.e. routing attribute value LSI comment number 14 Page=121 Subtype=Highlight Author=Brian Day Comment=There are a few dangling lines in the diagram LSI comment number 15 Page=130 Subtype=Highlight Author=Tim Hoglund Comment= this section should also discuss Phy test functionality provided by the SMP PHY TEST FUNCTION LSI comment number 16 Page=146 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 2 Delete Editor's Note 2 (and fix keys if they are indeed incorrect) LSI comment number 17 Page=146 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 1 Delete Editor's Note 1 (and fix keys if they are indeed incorrect) LSI comment number 18 Page=147 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 3 Delete Editor's Note 3 (and fix keys if they are indeed incorrect) LSI comment number 19 Page=153 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 4 Delete Editor's Note 4 (and fix signal assignments if they are indeed incorrect) LSI comment number 20 Page=154 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 5 Delete Editor's Note 5 (and fix signal assignments if they are indeed incorrect) LSI comment number 21 Page=161 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 6 Delete Editor's Note 6 (and fix signal assignments if they are indeed incorrect) LSI comment number 22 Page=162 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 7 Delete Editor's Note 7 (and fix signal assignments if they are indeed incorrect) LSI comment number 23 Page=165 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 8 Delete Editor's Note 8 (and fix signal assignments if they are indeed incorrect) LSI comment number 24 Page=166 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 9 Delete Editor's Note 9 (and fix signal assignments if they are indeed incorrect) LSI comment number 25 Page=167 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 10 Delete Editor's Note 10 (and fix keys if they are indeed incorrect) LSI comment number 26 Page=168 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 11 Delete Editor's Note 11 (and fix keys if they are indeed incorrect) LSI comment number 27 Page=252 Subtype=Highlight Author=Tim Hoglund Comment=change back to OPEN_REJECT (RESERVED STOP 0). see 05-145r0. LSI comment number 28 Page=256 Subtype=Highlight Author=Tim Hoglund Comment=change back to OPEN_REJECT (RESERVED STOP 0). see 05-145r0. LSI comment number 29 Page=256 Subtype=Highlight Author=Tim Hoglund Comment=change back to OPEN_REJECT (RESERVED STOP 0). see 05-145r0. LSI comment number 30 Page=269 Subtype=Highlight Author=Tim Hoglund Comment= remove clause b) see 05-145r0 LSI comment number 31 Page=269 Subtype=Highlight Author=Tim Hoglund Comment=change back to OPEN_REJECT (RESERVED STOP 0). see 05-145r0. LSI comment number 32 Page=269 Subtype=Highlight Author=Tim Hoglund Comment=change back to OPEN_REJECT (RESERVED STOP 0). see 05-145r0. LSI comment number 33 Page=270 Subtype=Highlight Author=Brian Day Comment= Should this be an item 4) instead of combined together with item 3)? LSI comment number 34 Page=315 Subtype=Highlight Author=Brian Day Comment= Need to pass up STP Resources Busy to match up with Table 107 in Port Layer. LSI comment number 35 Page=318 Subtype=Highlight Author=Tim Hoglund Comment= functional issue -- this behavior does not completely solve BREAK timing problems. see 05-145r0 for further details. LSI comment number 36 Page=327 Subtype=Highlight Author=Tim Hoglund Comment= ...shall occur if: a) a Forward_Open indication has not been received; and b) a BREAK Received message is received LSI comment number 37 Page=327 Subtype=Highlight Author=Tim Hoglund Comment= Remove dependency on BREAK Received message. Honor the Forward Open indication and a pass both OPEN Address Frame Received argument and BREAK Received argument in the transition to XL5:Forward_Open. LSI comment number 38 Page=333 Subtype=Highlight Author=Tim Hoglund Comment= functional issue -- this behavior does not completely solve BREAK timing problems. see 05-145r0 for further details. LSI comment number 39 Page=376 Subtype=Highlight Author=Brian Day Comment= Should be "Upon entry into this state," This state doesn't receive Tx Open messages. The Tx Open caused the PL_PM1 to PL_PM2 transition. LSI comment number 40 Page=377 Subtype=Highlight Author=Brian Day Comment=should be "Inbound" LSI comment number 41 Page=377 Subtype=Highlight Author=Brian Day Comment=should be "an" LSI comment number 42 Page=380 Subtype=Highlight Author=Brian Day Comment= It is not possible to be in this state during a connection, as the connection was never established. Suggest something like "as the result of an SMP connection request". LSI comment number 43 Page=380 Subtype=Highlight Author=Brian Day Comment= I think this needs to be Connection Closed(Transition to Idle) specifically. Otherwise, PL_PM3 state will exit as soon as the first Connection Closed happens. LSI comment number 44 Page=396 Subtype=Highlight Author=Brian Day Comment= In addition to XFER_RDY being received, I thought during conference call we were going to add DATA frame for a read command here as well. LSI comment number 45 Page=399 Subtype=Highlight Author=Brian Day Comment= Unless section 9.2.5 is removed entirely, there should be a sentence here that says transport layer retries are not included in the summary. LSI comment number 46 Page=399 Subtype=Highlight Author=Brian Day Comment= Replace this sentence with: If an SSP initiator port receives a RESPONSE frame with a RETRANSMIT bit set to one, and it has not previously received a RESPONSE frame for the same I_T_L_Q nexus, then the RESPONSE frame is valid. LSI comment number 47 Page=400 Subtype=Highlight Author=Brian Day Comment=should be "the" LSI comment number 48 Page=406 Subtype=Highlight Author=Brian Day Comment= Relative to comment in section 9.2.6.2.3.7.1, this may need to be ACK/NAK Timeout instead of Command Failed, Connection Failed. LSI comment number 49 Page=408 Subtype=Highlight Author=Brian Day Comment= I think this is supposed to be a generic Transmission Complete, not specifically a "Connection Failed", where the specific parameter is from item a) in the list following this paragraph. LSI comment number 50 Page=408 Subtype=Highlight Author=Brian Day Comment= I think need to add "or a COMMAND frame" if supporting retrying the COMMAND frame at least once, per last sentence of 9.2.4.2 LSI comment number 51 Page=409 Subtype=Highlight Author=Brian Day Comment= I think this sentence conflicts with 9.2.4.2 and 10.2.2. After a command transmission gets an ACK/NAK timeout, application layer is running a QUERY TASK. At ACK/NAK Timeout, the ST_ITS sent up the Transmission Complete(Command Failed, Connection Failed). IF XFER_RDY now comes in before the response for the QUERY TASK, it is supposed to be valid. LSI comment number 52 Page=409 Subtype=Highlight Author=Brian Day Comment= Need to add the retries case to not conflict with last sentence of 9.2.4.2. "The Transmit Frame request was for a COMMAND frame, and the vendor-specific number of retires has been reached." LSI comment number 53 Page=410 Subtype=Highlight Author=Brian Day Comment=should be "ST_IFR" LSI comment number 54 Page=410 Subtype=Highlight Author=Brian Day Comment=should be "ST_IFR" LSI comment number 55 Page=413 Subtype=Highlight Author=Brian Day Comment= Based on previous paragraph comment, this paragraph may not be accurate. LSI comment number 56 Page=413 Subtype=Highlight Author=Brian Day Comment= I think this should be ACK/NAK Timeout instead of Command Failed, Connection Failed, to not conflict with 9.2.4.2 and 10.2.2 to allow command frame retires. LSI comment number 57 Page=413 Subtype=Highlight Author=Brian Day Comment=should be "Reception" LSI comment number 58 Page=422 Subtype=Highlight Author=Brian Day Comment= think this is supposed to be a generic Transmission Complete, not specifically a "Connection Failed", where the specific parameter is from item b) in the list following this paragraph. LSI comment number 59 Page=450 Subtype=Highlight Author=Brian Day Comment= I think values for anything 1 ms or greater may conflict with the port and link layer state machines. For connections that the target establishes, in section 8.2.2.3.5, the PL_OC will close the connection, essentially bypassing the bus inactivity timer. For connections, the initiator establishes: 1) the initiator may has sent DONE, an is running the DONE Timeout timer. Not closing within 1ms results in BREAK. 2) The timer may never be started in this connection in section 8.2.3.4 PL_PM3, if the target doesn't have a frame to transmit. LSI comment number 60 Page=477 Subtype=Highlight Author=Tim Hoglund Comment= informative note vs normative shall? this is stated as an expander requirement but really is a capacity/topology consideration for cascading multiple expanders... LSI comment number 61 Page=565 Subtype=Highlight Author=Tim Hoglund Comment=change back to OPEN_REJECT (RESERVED STOP 0). see 05-145r0. LSI comment number 62 Page=613 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 13 Resolve this note. LSI comment number 63 Page=613 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 12 Resolve this note. LSI comment number 64 Page=614 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 16 Resolve this note. LSI comment number 65 Page=614 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 15 Resolve this note. LSI comment number 66 Page=614 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 14 Resolve this note. LSI comment number 67 Page=615 Subtype=Highlight Author=John Lohmeyer Comment= Editor's Note 17 Resolve this note. ************************************************************** Comments attached to No ballot from Mark Evans of Maxtor Corp.: Summary of Comments on the Serial Attached SCSI 1.1 (SAS-1.1) Standard Mark Evans Maxtor Corporation Maxtor comment # 1 Page: 1 Global: There are hundreds of occurrences of unclear pronoun references in this document. While reviewing the document for letter ballot, I only had time to comment on the ones that I thought were the most unclear. The general rule for pronoun usage is: there shall be no other noun forms (noun, pronoun, gerund, etc.) between a pronoun and the noun to which it is referring. The editor should correct any unclear pronoun references by replacing the unclear pronoun with the correct noun as he discovers the occurrences. Hint: one could start this process by searching on "it", then move on by searching on "they". Maxtor comment # 2 Page: 4 2.3: SES-2 is mentioned in many places and should be included here. Maxtor comment # 3 Page: 6 3.1.11: Change to: an I/O subsystem that is made up of one host, one or more devices, and a service delivery subsystem. [as defined by the T13 Technical Committee.] Maxtor comment # 4 Page: 7 3.1.28: Change to: Information passed from a lower layer state machine to a higher layer state machine, usually responding to a request (see 3.1.153) from that higher layer state machine. See 3.6. Maxtor comment # 5 Page: 9 3.1.52, item (a): Change, "ideal bit time" to "average bit time". [this allows for frequency tolerances.] Maxtor comment # 6 Page: 9 3.1.66: Change to: An object within an expander device that contains one or more phys and interfaces to the service delivery subsystem and to SAS ports in other devices (see x.x). Maxtor comment # 7 Page: 10 3.1.67: Define "routed SAS address". Maxtor comment # 8 Page: 10 3.1.71: Change "vs." to "versus". Maxtor comment # 9 Page: 10 3.1.71, second sentence: Change to: Comparison of the measured eye contour to the jitter eye masks determines if a jitter eye mask violation has occurred (see 5.3.6). Maxtor comment # 10 Page: 10 3.1.73: Add "(See x.x)" where x.x is the number of the clause where this device is described in detail. Maxtor comment # 11 Page: 10 3.1.75: Change "e.g." to "i.e." in two places. Maxtor comment # 12 Page: 10 3.1.84: Add "(See SAM-3)". Maxtor comment # 13 Page: 10 3.1.86: Add "(See SAM-3)". Maxtor comment # 14 Page: 11 3.1.87: Add "(See SAM-3)". Maxtor comment # 15 Page: 11 3.1.91: Change to: Information passed from a lower layer state machine to a higher layer state machine, usually relaying a request (see 3.1.153) from a peer layer state machine. See 3.6. Maxtor comment # 16 Page: 13 3.1.124: Change "after" to "as the result of". Maxtor comment # 17 Page: 14 3.1.143: Change to: A mathematical representation of the likelihood of occurrence of various events. When applied to a jitter event population, it describes the histograph of measured jitter values. Maxtor comment # 18 Page: 15 3.1.153: Change to: Information passed from a higher layer state machine to a lower layer state machine, usually to initiate some action. See 3.6. Maxtor comment # 19 Page: 15 3.1.154: Change "from" to "in". Maxtor comment # 20 Page: 15 3.1.155: Change to: Information passed from a higher layer state machine to a lower layer state machine, usually in response to an indication (see 3.1.91). See 3.6. Maxtor comment # 21 Page: 15 3.1.156: Delete the last sentence ("All SAS receiver devices shall be retimers."). Maxtor comment # 22 Page: 19 3.1.240: Change "A physical entity..." to "A physical entity contained in a SAS port..." Maxtor comment # 23 Page: 19 3.1.241: Change to: An electronic circuit that converts a logical signal to an analog serial output signal. Maxtor comment # 24 Page: 26 3.5: Figure 3 is the first of many instances where it is difficult to determine what all is included in the figure. In these cases it would be helpful to put a box around all of the items in the figures, or somehow group them in some other way. Maxtor comment # 25 Page: 32 3.6.3, third paragraph: Change, "...going to the top or bottom..." to, "...going toward the top or bottom...". Maxtor comment # 26 Page: 32 3.6.4: Change, "They are created..." to, "Counters, timers and variables are created...". Maxtor comment # 27 Page: 35 4.1.2, second paragraph: Change, "...which attaches to another physical phy." to, "which attaches to a physical phy in another device.". Maxtor comment # 28 Page: 47 4.1.8.1: Change, "Some of them..." to, "Expander devices...". Maxtor comment # 29 Page: 48 4.1.8.2, paragraph 7: Change to: An edge expander device set may be attached to one other edge expander device set if: a) the expander device set is the only other edge expander device set in the SAS domain; b) the expander device set is attached using expander phys with subtractive routing attributes; and c) there are no fanout expander devices in the SAS domain. Maxtor comment # 30 Page:48 4.1.8.3, second sentence: Change to: A fanout expander device may be attached to up to 128 SAS ports. Maxtor comment # 31 Page: 52 4.1.10, second paragraph: Change, "...when an OPEN_ACCEPT is returned to the source phy." to, "...when an OPEN_ACCEPT is received by the source phy." Maxtor comment # 32 Page: 67 4.4.1, first paragraph: Change "describes" to "illustrates". Maxtor comment # 33 Page: 72 4.6.2, fourth paragraph: Change, "...within an expander port requests and responds to connection requests..." to, "...within an expander port requests connections and responds to connection requests...". Maxtor comment # 34 Page: 72 4.6.2, fifth paragraph: Change "SES" to "see SES-2". Maxtor comment # 35 Page: 76 Table 12, second column, fifth row (Arbitrating (Waiting On Connection)): Change "block" to "blocked". Maxtor comment # 36 Page: 77 Table 12, second column, eighth row (Arb Reject (Bad Destination)): Change to: Confirmation that the ECM has determined that: a) the requested destination SAS address maps back to the requesting port; b) the requesting port is using the direct routing method; or c) the requesting port is using the table routing method, and the EM has not chosen to return Arb Reject (No Destination) (see 7.12.5.2 and 7.12.5.3). Maxtor comment # 37 Page: 83 4.7.2, fourth paragraph: Change, "...it shall disable the expander route entry...", to, "...the management application client shall disable the expander route entry...". Maxtor comment # 38 Page: 105 5.2.3.3.6, fifth paragraph: Change, "Based on what device are using the connector...", to, "Based on what device is using the connector...". Maxtor comment # 39 Page: 107 Editor's Note 1: This is the first of many notes stating that something may be incorrect. Correct whatever is incorrect in each case and delete the note. Maxtor comment # 40 Page: 119 5.2.4.2, lettered list: correct the lettering. Maxtor comment # 41 Page: 119 5.2.4.3.1, second lettered list: correct the lettering. Maxtor comment # 42 Page: 120 NOTE 8: Change "controller to backplane" to "controller-to-backplane". Maxtor comment # 43 Page: 121 NOTE 9: Change "controller to controller" to "controller-to-controller". Maxtor comment # 44 Page: 121 NOTE 10: Change "controller to controller" to "controller-to-controller". Maxtor comment # 45 Page: 123 NOTE 13: Change "controller to controller" to "controller-to-controller". Maxtor comment # 46 Page: 138 5.3.1, paragraph above figure 88: Change, "It also shows...", to, "Figure 88 also shows...". Maxtor comment # 47 Page: 145 5.3.3, fourth paragraph: Change the first sentence to: The TxRx connection shall have a BER that is less than the objective of 10-12. Maxtor comment # 48 Page: 146 Table 34, note b: Change "i.e." to "e.g.". Maxtor comment # 49 Page: 148 5.3.4, list item e: Change, "enabling and disabling pre-emphasis (i.e., de-emphasis)" to, "enabling pre-emphasis or disabling preemphasis (i.e., de-emphasis)". Maxtor comment # 50 Page: 151 5.3.7.1, third paragraph: Delete "(i.e., de-emphasis)". Maxtor comment # 51 Page: 153 Table 38, note d: Change "i.e." to "e.g.". Maxtor comment # 52 Page: 156 Table 40, note d: Change "i.e." to "e.g.". Maxtor comment # 53 Page: 162 6.3.3, seventh paragraph: Change the first sentence to: All sub-blocks with equal numbers of zeros and ones have neutral disparity (i.e., the ending disparity is the same as the beginning disparity) with the exceptions noted above. Maxtor comment # 54 Page: 171 6.6.1, first paragraph: In the first sentence, change "the phy" to "a phy". Maxtor comment # 55 Page: 171 6.6.1, first paragraph: In the second sentence, change, "They consist of...", to, "OOB signals consist of..." Maxtor comment # 56 Page: 172 6.6.2, third paragraph: Change, "It shall then transmit...", to, "The transmitter device shall then transmit..." Maxtor comment # 57 Page: 172 6.6.2, sixth paragraph: Change to: A SAS transmitter device: a) should transmit ALIGNs at the G1 physical link rate to create the burst portion of the OOB signal; b) may transmit ALIGNs at the lowest physical link rate supported by the SAS transmitter device if it is not able to transmit at the G1 physical link rate; and c) shall not transmit ALIGNs at a physical link rate faster than the lowest physical link rate supported by the SAS transmitter device. Maxtor comment # 58 Page: 174 6.6.5, fifth paragraph: Add the following sentence: A SAS receiver device is not required to identify the ALIGNs in the burst. Maxtor comment # 59 Page: 187 6.8.1. fourth paragraph: Change to: The SP state machine shall maintain a MgmtReset state machine variable to determine whether SP0:OOB_COMINIT was last entered as the result of a Management Reset or a transition from another state (see 6.8.3.2.1). If SP0:OOB_COMINIT was last entered as the result of a Management Reset, then the SP state machine shall set the MgmtReset state machine variable to one. If SP0:OOB_COMINIT was last entered as the result of a transition from another state, then the SP state machine shall set the MgmtReset state machine variable to zero. Any transition from SP7:OOB_AwaitCOMSAS shall cause the SP state machine to set the MgmtReset state machine variable to zero. Maxtor comment # 60 Page: 187 6.8.1. fifth paragraph: Change to: If the phy supports attachment to a SATA device (i.e., the phy is contained in an STP/SATA bridge), and the phy supports attachment to a SATA port selector, then the SP state machine shall maintain a COMWAKE_Received state machine variable to determine whether a COMWAKE detected message was received in SP0:OOB_COMINIT or SP1:OOB_AwaitCOMX since the last time SP0:OOB_COMINIT was entered. A COMWAKE Detected message received in SP0:OOB_COMINIT or SP1:OOB_AwaitCOMX shall cause the SP state machine to set the COMWAKE_Received state machine variable to one. Any transition to SP0:OOB_COMINIT shall cause the SP state machine to set the COMWAKE_Received state machine variable to zero. Maxtor comment # 61 Page: 188 6.8.2, third paragraph: Change "idle time" to "D.C. idle". Maxtor comment # 62 Page: 190 6.8.3.2.1, fifth paragraph: Change to: If: a) the phy supports attachment to a SATA device (i.e., the phy is contained in an STP/SATA bridge); b) the phy supports attachment to a SATA port selector; and c) this state receives a COMWAKE Detected message; then this state shall set the COMWAKE_Received state machine variable to one, and, if the value of the ATTACHED SATA PORT SELECTOR bit in the DISCOVER response is zero, this state shall: a) set the ATTACHED SATA PORT SELECTOR bit in the DISCOVER response to one; and b) send a SATA Port Selector Change confirmation to the link layer. Maxtor comment # 63 Page: 190 6.8.3.2.1, sixth paragraph: Change to: The state machine shall set the MgmtReset state machine variable to one if this state is entered as the result of receiving a Management Reset request or an SMP Reset request. The state machine shall set the MgmtReset state machine variable to zero if this state is entered as the result of receiving: a) a power on or hard reset request; b) a DWS Lost message; or c) a COMINIT Detected message. Maxtor comment # 64 Page: 190 6.8.3.3.1, second paragraph: Change to: If: a) the phy supports attachment to a SATA device (i.e., the phy is contained in an STP/SATA bridge); b) the phy supports attachment to a SATA port selector; and c) this state receives a COMWAKE Detected message; then this state shall set the COMWAKE_Received state machine variable to one, and, if the value of the ATTACHED SATA PORT SELECTOR bit in the DISCOVER response is zero, this state shall: a) set the ATTACHED SATA PORT SELECTOR bit in the DISCOVER response to one; and b) send a SATA Port Selector Change confirmation to the link layer. Maxtor comment # 65 Page: 191 6.8.3.3.2, second paragraph: Change to: If the phy supports attachment to a SATA device (i.e., the phy is contained in an STP/SATA bridge) and supports attachment to a SATA port selector, then the state machine shall check the value of the COMWAKE_Recieved state machine variable prior to this transition. If the COMWAKE_Received state machine variable is set to zero and the ATTACHED SATA PORT SELECTOR bit in the DISCOVER response is set to one, then the state machine shall set the ATTACHED SATA PORT SELECTOR bit in the DISCOVER response to zero and shall send a SATA Port Selector Change confirmation to the link layer. Maxtor comment # 66 Page: 191 6.8.3.5.1, second paragraph: Change to: If: a) this state receives COMWAKE Detected message; b) the phy supports attachment to a SATA device (i.e., the phy is contained in an STP/SATA bridge); c) the phy supports attachment to a SATA port selector; and d) the value of the ATTACHED SATA PORT SELECTOR bit is zero in the DISCOVER response; then this state shall set the ATTACHED SATA PORT SELECTOR bit in the DISCOVER response to one and send a SATA Port Selector Change confirmation to the link layer. Maxtor comment # 67 Page: 191 6.8.3.6.1, second paragraph: Change to: If: a) this state receives COMWAKE Detected message; b) the phy supports attachment to a SATA device (i.e., the phy is contained in an STP/SATA bridge); c) the phy supports attachment to a SATA port selector; and d) the value of the ATTACHED SATA PORT SELECTOR bit is zero in the DISCOVER response; then this state shall set the ATTACHED SATA PORT SELECTOR bit in the DISCOVER response to one and send a SATA Port Selector Change confirmation to the link layer. Maxtor comment # 68 Page: 192 6.8.3.6.1, third paragraph: See the previous comment. Maxtor comment # 69 Page: 192 6.8.3.6.2, second paragraph: Change "bit is one" to "bit is set to one" and "bit is zero" to "bit is set to zero". Maxtor comment # 70 Page: 192 6.8.3.6.3, second paragraph: Change "bit is one" to "bit is set to one" and "bit is zero" to "bit is set to zero". Maxtor comment # 71 Page: 195 6.8.4.2.1, second paragraph: Change item (a) to, 'initialize and start the RCDT timer (this provides the time required for a transmitter to switch to either the next higher or next lower supported speed negotiation window rate); and' Maxtor comment # 72 Page: 195 6.8.4.2.1, third paragraph: Change to: The argument for the Set Rate message shall be: a) 1.5 Gbps (if the transition into this state was from the SP6:OOB_AwaitNoCOMSAS state); or b) the value of the SAS Speed Negotiation Window Rate argument. Maxtor comment # 73 Page: 196 6.8.4.5.3: Change "lock" to "achieve dword synchronization". Maxtor comment # 74 Page: 196 6.8.4.5.4: Change "lock" to "achieve dword synchronization". Maxtor comment # 75 Page: 197 6.8.4.8.1, lettered list: Change "window" to "window rate" in three places. Maxtor comment # 76 Page: 197 6.8.4.8.2, lettered list: Change "window" to "window rate" in two places. Change "haven't" to "have not". Maxtor comment # 77 Page: 197 6.8.4.8.3, lettered lists: Change "window" to "window rate" in five places. Maxtor comment # 78 Page: 198 See previous comment. Maxtor comment # 79 Page: 228 7.2.5.9, eighth paragraph: Change to: When a SAS target devices with multiple SAS target ports receives a NOTIFY (ENABLE SPINUP) on any of its SAS target ports, the SAS target device transitions from the Active_Wait or Idle_Wait state (see 10.2.10). For example, if a SAS target device contains two SAS target ports (port A and port B), powers on in the Stopped state, and receives a START STOP UNIT command with the START bit set to one through SAS target port A, then a NOTIFY (ENABLE SPINUP) received on SAS target port B causes the SAS target device to spin up its rotating media. Maxtor comment # 80 Page: 238 7.5.3, second paragraph: In the last sentence, change "Mathematically, the..." to "The...". Maxtor comment # 81 Page: 243 7.8.1, first paragraph: Change the second sentence to: An address frame is delimited by a preceding SOAF and a following EOAF. Maxtor comment # 82 Page: 250 7.9.3, first paragraph: Change the second sentence to be: The expander device may return OPEN_REJECT (NO DESTINATION) in response to OPEN address frames until the expander device is ready to process connection requests. Maxtor comment # 83 Page: 250 7.9.4, first paragraph: Change the second sentence to be: The expander device may return OPEN_REJECT (NO DESTINATION) in response to OPEN address frames until the expander device is ready to process connection requests. Maxtor comment # 84 Page: 257 7.11., lettered list, item b: Change to: 'after a virtual phy has been disabled with the SMP PHY CONTROL function DISABLE phy operation or has begun its internal reset as the result of receiving a LINK RESET or HARD RESET phy operation (see 10.4.3.10);' Maxtor comment # 85 Page: 257 7.11., lettered list, item g: Change to: 'after a virtual phy has been enabled or completed an internal reset as the result of receiving an SMP PHY CONTROL function LINK RESET or HARD RESET phy operation (see 10.4.3.10);' Maxtor comment # 86 Page: 258 7.12.1, first paragraph: Change "communication" to "SSP frame, SMP frame, or SATA FIS transmission". Maxtor comment # 87 Page: 258 7.12.2.1, third paragraph: Change the last sentence to: If the Open Timeout timer expires before a connection response is received, the source phy shall transmit BREAK to abort the connection request (see 7.12.6). Maxtor comment # 88 Page: 262 7.12.4.4, first paragraph: Change the second sentence to: Pathway recovery priority comparisons compare the values described in table 95 from the OPEN address frames of the blocked connection requests. Maxtor comment # 89 Page: 269 7.13, first paragraph after figure 140: Change, "A phy shall start inserting ALIGNs and/or NOTIFYs for rate matching at the selected connection rate with the first dword...", to, "A phy shall start inserting ALIGNs and/or NOTIFYs for rate matching at the selected connection rate after the first dword..." Maxtor comment # 90 Page: 291 7.15.9.1, fourth paragraph: Change the first sentence to: This state shall send the following responses received by one phy through the ECR to a source phy as confirmations: Maxtor comment # 91 Page: 291 7.15.9.1, fifth paragraph: Change the first sentence to: This state shall send the following responses received by one phy through the ECR to a source phy as confirmations: Maxtor comment # 92 Page: 294 7.15.13.1, second paragraph: Change, "Upon entry into this state, this state shall send:", to, "Upon entry into this state, this state shall:". Maxtor comment # 93 Page: 295 7.16.3, third paragraph: Change to: Receiving SSP phys shall acknowledge SSP frames within 1 ms (if the frame was not discarded as described in 7.16.7.7). The receiving phy shall send an ACK to acknowledge that the SSP frame was received into a frame buffer without errors. The receiving phy shall send a NAK (CRC ERROR) to acknowledge that the SSP frame was received with a CRC error, an invalid dword, or an ERROR primitive. Maxtor comment # 94 Page: 295 7.16.13, fourth paragraph: Change to: The transport layer (see 9.2.4) either retries sending SSP frames that encounter a link layer error (e.g., are NAKed or create an ACK/NAK timeout), or the application layer aborts the SCSI command associated with the SSP frame that encountered a link layer error. Maxtor comment # 95 Page: 303 7.16.7.3, fourth paragraph: Change to: When the number of Frame Transmitted messages received equals the number of ACK Received messages plus the number of NAK Received messages received, then the ACK/NAK count is balanced, and this state machine shall send a Tx Balance Status (Balanced) message to the SSP_TF2:Tx_Wait state. When the number of Frame Transmitted messages received does not equal the number of ACK Received messages plus the number of NAK Received messages received, then this the ACK/NAK count is not balanced and this state machine shall send a Tx Balance Status (Not Balanced) message to the SSP_TF2:Tx_Wait state. Maxtor comment # 96 Page: 303 7.16.7.3, first lettered list: Change item (a) to: decrement the ACK/NAK count by one. Maxtor comment # 97 Page: 303 7.16.7.3, second lettered list: Change item (a) to: decrement the ACK/NAK count by one. Maxtor comment # 98 Page: 309 7.16.7.9, third paragraph: Change, "...the number of the ACK Transmitted messages and the number of NAK Transmitted messages..." to, "...the number of the ACK Transmitted messages plus the number of NAK Transmitted messages..." Maxtor comment # 99 Page: 309 7.16.7.9, fourth paragraph: Change, "...the number of the ACK Transmitted messages and the number of NAK Transmitted messages..." to, "...the number of the ACK Transmitted messages plus the number of NAK Transmitted messages..." Maxtor comment # 100 Page: 333 8.2.2.3.6, last paragraph: Change to: If this state receives a Disable Tx Frames message from a PL_PM state machine, then this state should send no more Tx Frame messages to that state machine until after a new connection is established. Maxtor comment # 101 Page: 338 8.2.3.3.4, third paragraph: Change, "...Incoming Connection Rejected confirmation..." to, "...Inbound Connection Rejected confirmation...". Maxtor comment # 102 Page: 340 8.2.3.4.1, twenty-fourth paragraph (the next to last paragraph on page 340): Change, "...Connection Closed (Transition to Idle Confirmation)..." to, "...Connection Closed (Transition to Idle) confirmation..." Maxtor comment # 103 Page: 340 8.2.3.4.1, twenty-fifth paragraph (the last paragraph on page 340): Change, "...Connection Closed (Transition to Idle Confirmation)..." to, "...Connection Closed (Transition to Idle) confirmation..." Maxtor comment # 104 Page: 349 9.2.2.2, fourth paragraph: Change, "If TASK MANAGEMENT FUNCTION contains..." to, "If the TASK MANAGEMENT FUNCTION field contains..." Maxtor comment # 105 Page 349 9.2.2.2, fifth paragraph: Change, "If TASK MANAGEMENT FUNCTION is set..." to, "If the task management function is set..." Maxtor comment # 106 Page: 350 9.2.2.3, fifth paragraph: Change "a XFER_RDY" to "an XFER_RDY". Maxtor comment # 107 Page: 351 9.2.2.4, sixth paragraph: Change "a XFER_RDY" to "an XFER_RDY". Maxtor comment # 108 Page: 351 9.2.2.4, tenth paragraph (the next to last paragraph in the clause): Change to: The DATA OFFSET field shall be set to zero in the initial read DATA frame for a given command. If any additional read DATA frames are required for the command and transport layer retries are not being used, then the DATA OFFSET field shall be set to the data offset plus the data length of the previous DATA frame for the command. Maxtor comment # 109 Page: 351 9.2.2.4, eleventh paragraph (the last paragraph in the clause): Change to: The DATA OFFSET field shall be set to zero in the initial write DATA frame for a given command. If any additional write DATA frames are required for the command and transport layer retries are not being used, then the DATA OFFSET field shall be set to the data offset plus the data length of the previous DATA frame for the command. Maxtor comment # 110 Page: 357 9.2.4.2, first paragraph: Change to: If an SSP initiator port transmits a COMMAND frame and does not receive an ACK or NAK for that frame (e.g., times out, or the connection is broken), then: 1) the SSP_TF state machine closes the connection with DONE (ACK/NAK TIMEOUT) (see 7.16.7.6.5); 2) the application client sends a Send Task Management protocol service request for a QUERY TASK task management function to determine whether the command was received (see 10.2.2); 3) the transport layer constructs a TASK frame containing the task management function and the TAG OF TASK TO BE MANAGED field set to the tag of the COMMAND frame; and 4) the SSP initiator port transmits the TASK frame in a new connection with the SSP target port. Maxtor comment # 111 Page: 358 9.2.4.3, first paragraph: Change to: If an SSP initiator port transmits a TASK frame and does not receive an ACK or NAK for that frame (e.g., times out, or the connection is broken), then: 1) the SSP_TF state machine closes the connection with DONE (ACK/NAK TIMEOUT) (see 7.16.7.6.5); 2) the application client sends a Send Task Management protocol service request for a the same task management function (see 10.2.2); 3) the transport layer constructs a TASK frame containing the task management function and the TAG OF TASK TO BE MANAGED field set to the tag of the previous TASK frame; and 4) the SSP initiator port transmits the TASK frame in a new connection with the SSP target port. Maxtor comment # 112 Page: 358 9.2.4.3, third paragraph: Change to: If an SSP initiator port does not receive an ACK or a RESPONSE frame for a TASK frame, then the application client should send a Send Task Management protocol service request for a the same task management function and the SSP initiator port should transmit the TASK frame in a new connection to the SSP target port at least once. Maxtor comment # 113 Page: 358 9.2.4.4.2, first paragraph: Change to: If an SSP target port transmits an XFER_RDY frame and does not receive an ACK or NAK for that frame (e.g., times out, or the connection is broken), then: 1) the SSP_TF state machine closes the connection with DONE (ACK/NAK TIMEOUT) (see 7.16.7.6.5); 2) the ST_TTS state machine constructs a new XFER_RDY frame setting the RETRANSMIT bit set to one and setting the value in the TARGET PORT TRANSFER TAG field to a value that is different than the value in the TARGET PORT TRANSFER TAG field in the previous XFER_RDY frame (see 9.2.6.3.3.5); and 3) the SSP target port transmits the XFER_RDY frame in a new connection with the SSP initiator port. Maxtor comment # 114 Page: 358 9.2.4.4.2, second paragraph: Change to: If an SSP target port transmits an XFER_RDY frame and receives a NAK for that frame, then: 1) the ST_TTS state machine constructs a new XFER_RDY frame setting the RETRANSMIT bit set to one and setting the value in the TARGET PORT TRANSFER TAG field to a value that is different than the value in the TARGET PORT TRANSFER TAG field in the previous XFER_RDY frame (see 9.2.6.3.3.5); and 2) the SSP target port transmits the XFER_RDY frame to the SSP initiator port. Maxtor comment # 115 Page: 358 9.2.4.4.2, third paragraph: Change the last sentence to: The ST_ITS state machine does not send requests to transmit any additional write DATA frames for the previous XFER_RDY frame after sending a request to transmit a write DATA frame for the new XFER_RDY frame. Maxtor comment # 116 Page:358 9.2.4.4.3, first paragraph: Change to: If an SSP target port transmits an XFER_RDY frame and does not receive an ACK or NAK for that frame (e.g., times out, or the connection is broken), then: 1) the SSP_TF state machine closes the connection with DONE (ACK/NAK TIMEOUT) (see 7.16.7.6.5); 2) the device server sends a Send Command Complete protocol service request with CHECK CONDITION status for that command with the sense key set to ABORTED COMMAND and the additional sense code set to ACK/NAK TIMEOUT (see 10.2.3); 3) the transport layer constructs a RESPONSE frame containing the status, sense key, and additional sense code; and 4) the SSP target port transmits the RESPONSE frame in a new connection with the SSP initiator port. Maxtor comment # 117 Page: 359 9.2.4.4.3, second paragraph: Change to: If an SSP target port transmits an XFER_RDY frame and receives a NAK for that frame, then: 1) the device server sends a Send Command Complete protocol service request with CHECK CONDITION status for that command with the sense key set to ABORTED COMMAND and the additional sense code set to ACK/NAK TIMEOUT (see 10.2.3); 2) the transport layer constructs a RESPONSE frame containing the status, sense key, and additional sense code; and 3) the SSP target port transmits the RESPONSE frame to the SSP initiator port. Maxtor comment # 118 Page: 359 9.2.4.5.2, first paragraph: Change to: If an SSP target port transmits a read DATA frame and does not receive an ACK or NAK for that frame (e.g., times out, or the connection is broken), then: 1) the SSP_TF state machine closes the connection with DONE (ACK/NAK TIMEOUT) (see 7.16.7.6.5); and 3) the SSP target port retransmits, in a new connection with the SSP initiator port, all of the read DATA frames since a previous time when ACK/NAK balance occurred (see 9.2.6.3.3.4). Maxtor comment # 119 Page: 359 9.2.4.5.2, second paragraph: Change to: If an SSP target port transmits a read DATA frame and receives a NAK for that frame, then, in the same or in a new connection, the SSP target port retransmits all of the read DATA frames since a previous time when ACK/NAK balance occurred (see 9.2.6.3.3.4). Maxtor comment # 120 Page: 359 9.2.4.5.2, third paragraph: Change to: If an SSP initiator port transmits a write DATA frame and does not receive an ACK or NAK for that frame (e.g., times out, or the connection is broken), then: 1) the SSP_TF state machine closes the connection with DONE (ACK/NAK TIMEOUT) (see 7.16.7.6.5); and 3) the SSP initiator port retransmits, in a new connection with the SSP target port, all of the write DATA frames since a previous time when ACK/NAK balance occurred (see 9.2.6.2.3). Maxtor comment # 121 Page: 359 9.2.4.5.2, fourth paragraph: Change to: If an SSP initiator port receives a new XFER_RDY frame or a RESPONSE frame for a command while retransmitting or preparing to retransmit write DATA frames for that command, then the ST_IFR state machine and ST_ITS state machine stops sending requests to retransmit the write DATA frames and processes the XFER_RDY frame or RESPONSE frame (see 9.2.6.2.2 and 9.2.6.2.3). The ST_ITS state machine does not send a request to transmit a write DATA frame for the previous XFER_RDY frame after sending a write DATA frame in response to the new XFER_RDY frame. Maxtor comment # 122 Page: 359 9.2.4.5.2, fifth paragraph: Change to: If an SSP initiator port transmits a write DATA frame and receives a NAK for that frame, then, in the same or in a new connection, the SSP initiator port retransmits all of the write DATA frames since a previous time when ACK/NAK balance occurred (see 9.2.6.3.3.4). Maxtor comment # 123 Page: 359 9.2.4.5.2, seventh paragraph: Change to: The ST_ITS state machine and ST_TTS state machine send requests to retransmit each DATA frame that does not receive an ACK at least one time (see 9.2.6.2.3 and 9.2.6.3.3). The number of times the state machines retransmit each DATA frame is vendor-specific. Maxtor comment # 124 Page: 360 9.2.4.5.3, first paragraph: Change to: If an SSP target port transmits a read DATA frame and does not receive an ACK or NAK for that frame (e.g., times out, or the connection is broken), then: 1) the SSP_TF state machine closes the connection with DONE (ACK/NAK TIMEOUT) (see 7.16.7.6.5); 2) the device server sends a Send Command Complete protocol service request with CHECK CONDITION status for that command with the sense key set to ABORTED COMMAND and the additional sense code set to ACK/NAK TIMEOUT (see 10.2.3); 3) the transport layer constructs a RESPONSE frame containing the status, sense key, and additional sense code; and 4) the SSP target port transmits the RESPONSE frame in a new connection with the SSP initiator port. Maxtor comment # 125 Page: 360 9.2.4.5.3, second paragraph: Change to: If an SSP target port transmits a read DATA frame and receives a NAK for that frame, then: 1) the device server sends a Send Command Complete protocol service request with CHECK CONDITION status for that command with the sense key set to ABORTED COMMAND and the additional sense code set to ACK/NAK TIMEOUT (see 10.2.3); 2) the transport layer constructs a RESPONSE frame containing the status, sense key, and additional sense code; and 3) the SSP target port transmits the RESPONSE frame to the SSP initiator port. Maxtor comment # 126 Page: 360 9.2.4.5.3, third paragraph: Change to: If an SSP initiator port transmits a write DATA frame and does not receive an ACK or NAK for that frame (e.g., times out, or the connection is broken), then: 1) the SSP_TF state machine closes the connection with DONE (ACK/NAK TIMEOUT) (see 7.16.7.6.5); and 2) the application client aborts the command (see 10.2.2). Maxtor comment # 127 Page: 360 9.2.4.5.3, fourth paragraph: Change to: If an SSP initiator port transmits a write DATA frame and receives a NAK for that frame, the application client aborts the command (see 10.2.2). Maxtor comment # 128 Page: 360 9.2.4.6, first paragraph: Change to: If an SSP target port transmits a RESPONSE frame and does not receive an ACK or NAK for that frame (e.g., times out, or the connection is broken), then: 1) the SSP_TF state machine closes the connection with DONE (ACK/NAK TIMEOUT) (see 7.16.7.6.5); 2) the ST_TTS state machine constructs a new RESPONSE frame using all of the values from the previous frame, except the RETRANSMIT bit is set to one (see 9.2.6.3.3); and 4) the SSP target port transmits the RESPONSE frame in a new connection with the SSP initiator port. Maxtor comment # 129 Page: 360 9.2.4.6, second paragraph: Change to: If an SSP target port transmits a RESPONSE frame and receives a NAK for that frame, the SSP target port retransmits the RESPONSE frame at least one time with the RETRANSMIT bit set to zero (see 9.2.6.3.3). Maxtor comment # 130 Page: 360 9.2.4.6, third paragraph: Change to: An SSP target port retransmits each RESPONSE frame that does not receive an ACK at least one time (see 9.2.6.3.3). The number of times the SSP target port retransmits each RESPONSE frame is vendor-specific. Maxtor comment # 131 Page: 360 9.2.4.6, fourth paragraph: Change to: If an SSP initiator port receives a new RESPONSE frame for an I_T_L_Q nexus with the RETRANSMIT bit set to one, and that SSP initiator port has previously received a RESPONSE frame for the same I_T_L_Q nexus, then the ST_TFR state machine discards the new RESPONSE frame (see 9.2.6.3.2). If the ST_TFR state machine had not previously received a RESPONSE frame for the I_T_L_Q nexus, then the state machine considers the new RESPONSE frame to be the valid RESPONSE frame for the I_T_L_Q nexus. Maxtor comment # 132 Page: 361 9.2.5.2, third paragraph: Change, "...he ST_IFR state machine..." to, "...the ST_IFR state machine...". Maxtor comment # 133 Page: 361 9.2.5.3, second paragraph: Change "the ST_TTS state machine" to "then the SSP target port". Maxtor comment # 134 Page: 361 9.2.5.3, third paragraph: Change "the ST_TTS state machine" to "then the SSP target port". Maxtor comment # 135 Page: 361 9.2.5.3, fourth paragraph: Change "the device server" to "then the SSP target port". Maxtor comment # 136 Page: 362 9.2.5.3, eighth paragraph: Change "the ST_TFR state machine" to "then the SSP target port". Maxtor comment # 137 Page: 362 9.2.5.3, ninth paragraph: Change "the ST_TFR state machine" to "then the SSP target port". Maxtor comment # 138 Page: 362 9.2.5.3, eleventh paragraph: Change to: If an SSP target port receives a write DATA frame with a data offset that was not expected, then: 1) the ST_TTS state machine discards the frame (see 9.2.6.3.3.6.1); 2) the device server sends a Send Command Complete protocol service request with CHECK CONDITION status for that command with the sense key set to ABORTED COMMAND and the additional sense code set to DATA OFFSET ERROR (see 10.2.3); 3) the transport layer constructs a RESPONSE frame containing the status, sense key, and additional sense code; and 4) the SSP target port transmits the RESPONSE frame in the same or a new connection with the SSP initiator port. Maxtor comment # 139 Page: 362 9.2.5.3, twelfth paragraph: Change to: If an SSP target port receives a write DATA frame with more write data than expected (i.e., the write DATA frame contains data in excess of that requested by an XFER_RDY frame or, for first burst data, indicated by the FIRST BURST LENGTH field in the Disconnect-Reconnect mode page), then: 1) the ST_TTS state machine discards the frame (see 9.2.6.3.3.6.1); 2) the device server sends a Send Command Complete protocol service request with CHECK CONDITION status for that command with the sense key set to ABORTED COMMAND and the additional sense code set to TOO MUCH WRITE DATA (see 10.2.3); 3) the transport layer constructs a RESPONSE frame containing the status, sense key, and additional sense code; and 4) the SSP target port transmits the RESPONSE frame in the same or a new connection with the SSP initiator port. Maxtor comment # 140 Page: 362 9.2.5.3, thirteenth paragraph: Change to: If an SSP target port receives a zero length write DATA frame, then: 1) the ST_TTS state machine discards the frame (see 9.2.6.3.3.6.1); 2) the device server sends a Send Command Complete protocol service request with CHECK CONDITION status for that command with the sense key set to ABORTED COMMAND and the additional sense code set to INFORMATION UNIT TOO SHORT (see 10.2.3); 3) the transport layer constructs a RESPONSE frame containing the status, sense key, and additional sense code; and 4) the SSP target port transmits the RESPONSE frame in the same or a new connection with the SSP initiator port. Maxtor comment # 141 Page: 362 9.2.5.3, add the following as a last paragraph: If an ST_TFR state machine receives any subsequent write DATA frames for a command that has been aborted, then the ST_TFR state machine discards those frames (see 9.2.6.3.2). Maxtor comment # 142 Page: 373 9.2.6.2.3.5.2: Change the clause heading to be bold. Maxtor comment # 143 Page: 400 Table 134 through 146: Change "specifies" and "indicates", as required, to be consistent with common practice. Maxtor comment # 144 Page: 433 10.4.3.1, fourth paragraph: Change, "The ADDITIONAL REQUEST BYTES field definition and length is based..." to, "The ADDITIONAL REQUEST BYTES field definition and length are based...". ************************************************************** Comments attached to No ballot from Jay Neer of Molex Inc.: 1. The information in the ballot was translated incorrectly from the original input for the tables and figures for the new Compact MultiLane connectors and needs to be corrected by the editor. 2. I agree with the 05-139r0 document that the duplicate technical information be removed for the new Compact MultiLane connector documentation; remove the tables and leave the figures. 3. I propose that the pin out proposed in 05-138r0 be used instead of the pin out proposed in the ballot. This proposed pin out will more closely follow the pin out requested by the committee at the last meeting and will facilitate having a cable assembly that is easier to manufacture. ************************************************************** Comments attached to Yes ballot from Bill Lye of PMC-Sierra: PMC #1 PDF Page 181 Section 5.3.2.2 Zero-length test load Second Paragraph "Figure 91" should be "Figure 92" PMC #2 PDF Page 184 Section 5.3.2.4 Low-loss TCTF test load Fourth Paragraph The equation for this TCTF are specified differently than either of the other two TCTF's, in that it specifies a smooth line from 50MHz to 5,0GHz while the other two equations specify kinks at 3,0GHz (3Gbps operation) or 1,5GHz (1.5Gbps operation). Should the Low-loss TCTF be similarly specified with kinks at 1,5GHz and 3,0GHz? As it stands with the current definition, the Low Loss TCTF actually allows more loss above 2,7GHz than the 1.5Gbit/s Internal TCTF, and is allows slightly more loss at 5,0GHz than the 3.0Gbit/s Internal TCTF, which makes the term "Low Loss" somewhat inaccurate. Although probably not relevant to this discussion, this TCTF also allows more loss than that allowed by the corresponding SATA2 cable specification. PMC #3 PDF Page 193 Table 38 - Transmitter device signal output.... Last line Note f has been applied to the entry (225mV) for 1,5Gbps IT Minimum OOB burst amplitude if attacing to a SATA device is supported. Note f allows 3,0Gbps ALIGN(0) dwords but does not allow 1,5 Gbps D24.3 characters. Suggestion is to apply note g instead. PMC #4 PDF Page 193 Table 38 - Transmitter device signal output.... Note g The text "... or 3,0 Gbps ALIGN(0) dwords (see SATA2-PHY)." implies that SATA2 may transmit 3,0 Gbps ALIGN(0) OOB bursts, when in fact SATA2 may only transmit 1,5 Gbps D24.3 characters or 1,5 Gbps ALIGN(0) dwords. Suggestion is to move the "(see SATA2-PHY)" to after "1,5 Gbps D24.3 characters". PMC #5 PDF Page 196 Table 40 - Delivered signal characteristics as measured.... Last line Note f has been applied to the entry (225mV) for 1,5Gbps IT Minimum OOB burst amplitude if attacing to a SATA device is supported. Note f allows 3,0Gbps ALIGN(0) dwords but does not allow 1,5 Gbps D24.3 characters. Suggestion is to apply note g instead. PMC #6 PDF Page 196 Table 40 - Delivered signal characteristics as measured.... Note g The text "... or 3,0 Gbps ALIGN(0) dwords (see SATA2-PHY)." implies that SATA2 may transmit 3,0 Gbps ALIGN(0) OOB bursts, when in fact SATA2 may only transmit 1,5 Gbps D24.3 characters or 1,5 Gbps ALIGN(0) dwords. Suggestion is to move the "(see SATA2-PHY)" to after "1,5 Gbps D24.3 characters". PMC #7 PDF Pages 513-514 Section B.2.2 Assumptions for the structure of the... Second enumerated list This list enumerates the individual components that a transmitter device contains. It may be preferrable if the order of the list were to better match what would normally be seen, i.e. a,b,e,f,g,c,d. PMC #8 PDF Page 513-514 Section B.2.2 Assumptions for the structure of the... Second enumerated list, last line The text "possibly ESD devices" should be "possibly ESD protection devices" PMC #9 PDF Page 514 Section B.2.2 Assumptions for the structure of the... Fourth enumerated list This list enumerates the individual components that a receiver device contains. It may be preferrable if the order of the list were to better match what would normally be seen, i.e. a,b,e,f,g,c,d. PMC #10 PDF Page 514 Section B.2.2 Assumptions for the structure of the... Fourth enumerated list, last line The text "possibly ESD devices" should be "possibly ESD protection devices" ************************************************************** Comments attached to Yes ballot from Craig W. Carlson of QLogic Corp.: Qlogic Corp #001 PDF page 328 7.15.4.5 Transition XL1:Request_Path to XL5:Forward_Open The following changes eliminate confusion regarding the arguments associated with the OPEN Address Frame received message. In the last sentence of this section, "This transition shall include an OPEN Address Frame Received argument containing the arguments received in the Forward Open indication.", replace "transition" with "state" and replace the end of the sentence beginning with "containing the arguments ..." with "with the transition.". Qlogic Corp #002 PDF page 328 7.15.4.5 Transition XL1:Request_Path to XL5:Forward_Open 7.15.4.6 Transition XL1:Request_Path to XL9:Break The following changes ensure that the Forward Open indication takes precedence over a simultaneous BREAK Received message. In the first sentence of 7.15.4.5, strike-through ", a BREAK Received message has not been received,". Add the following as the last sentence in this section. "If a BREAK Received message is received, this state shall include a BREAK Received argument with the transition." In 7.15.4.6, replace "after receiving a BREAK Received message" with "if a BREAK Received message is received and a Forward Open indication has not been received". ************************************************************** Comments attached to No ballot from Gerald Houlder of Seagate Technology: Comments are in document 05-147r0. ************************************************************** Comments attached to Yes ballot from William Martin of Sierra Logic, Inc.: Sierra_Logic-001 Page 303 clause 7.16.7.3 4th paragraph last sentence '. then this the ACK/NAK .' should be '. then the ACK/NAK .' Sierra_Logic-002 Page 304 clause 7.16.7.3 last paragraph I believe that this was intended to set the number of frames transmitted to zero, and the number of ACKS and NAKS received to zero. At a minimum indicate that the number of ACKs and NAKs received may be set to zero. Sierra_Logic-004 Page 437 clause 10.4.3.3 Last sentence of paragraph on EXPANDER CHANGE COUNT and first sentence of following paragraph - The first sentence here requires incrementing under certain conditions specified in 7.11; however, the second sentence makes this requirement optional. While there is the possibility of minimizing the number of BROADCAST(CHANGE) transmissions, the process will require more than this qualified sentence to make it correct for a normative reference. I would suggest removing the second highlighted sentence. ************************************************************** Comments attached to No ballot from Ashlie Fan of TycoElectronics: 1) Table 31 (for External Cables), page 131: Maximum Intra-pair skew: 20ps Comments: Compare to Table 32 (For Internal Wide Cables), 20ps is not practically possible. External cable is expected to be several times longer than internal cables, but the skew budget is not. Suggest: Need to propose a reasonable budget or leave it off the spec until a reasonable budget is determined 2) Table 31 and Table 32: Maximum Crosstalk Comments: the descriptions of the requirements are not clear Suggest: change description to match how the measurement should take place, such as how many aggressor at one time and how many victim lines should be considered and their position. If more than one victim line is measured, the spec requirement is a total sum? 3) General comments: Cable, Media, Cable Assembly Comments: Cable, Media and Cable Assembly have been used in this document. They cause confusions Suggest: Need more clarification about these terms: does 'cable' mean 'cable assembly'?does 'media' mean cable/backplane without connector and termination? etc ************************************************************** Comments attached to Abs ballot from Roger Cummings of Veritas Software: Not with our organization's area of interest ******************** End of Ballot Report ********************