From lohmeyer at t10.org Sat Sep 7 23:01:30 2013 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 8 Sep 2013 00:01:30 -0600 Subject: Recent T10 documents uploaded since 2013/09/01 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SBC-4 SPC-5 Scattered writes, optionally atomic (by: Rob Elliott, Ashish Batwara, Walt Hubis) T10/12-086r5 Uploaded: 2013/09/05 218936 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-086r5.pdf SBC-4 Gathered reads, optionally atomic (by: Rob Elliott, Ashish Batwara, Walt Hubis) T10/12-087r5 Uploaded: 2013/09/05 179478 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-087r5.pdf SBC-4 SPC-5 Atomic writes and reads (by: Rob Elliott, Ashish Batwara, Walt Hubis) T10/13-064r4 Uploaded: 2013/09/05 342384 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-064r4.pdf SBC-3 Letter Ballot Comments Resolutions (by: George Penokie) T10/13-089r7 Uploaded: 2013/09/04 7717296 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-089r7.fdf SBC-3 Letter Ballot Comments Resolutions (by: George Penokie) T10/13-089r7 Uploaded: 2013/09/04 7665982 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-089r7.pdf SOP Letter Ballot Comments (by: Curtis Stevens) T10/13-108r2 Uploaded: 2013/09/02 10159026 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-108r2.pdf SPC-4 LB Timestamps model rewrite (by: Ralph Weber) T10/13-133r3 Uploaded: 2013/09/04 128891 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-133r3.pdf SPC-4 LB Only needed Sense Data Descriptors (by: Ralph Weber) T10/13-187r1 Uploaded: 2013/09/04 84388 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-187r1.pdf SPL-3: Missing Obsolete notation and other issues from 09-374 (by: George Penokie) T10/13-206r2 Uploaded: 2013/09/03 70198 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-206r2.pdf SBC-3 Define read, verify, and write operations (by: Rob Elliott) T10/13-213r1 Uploaded: 2013/09/04 282756 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-213r1.pdf SPL-3: Persistent Connection Establishment Fix (by: George Penokie) T10/13-222r0 Uploaded: 2013/09/03 70709 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-222r0.pdf SAS-3 letter ballot comment regarding SAS3_EYEOPENING issues (by: Alvin Cox) T10/13-223r0 Uploaded: 2013/09/05 40093 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-223r0.pdf Working Drafts -------------- Serial Attached SCSI - 3 (SAS-3) (Editor: Alvin Cox) Rev: 05g Uploaded: 2013/09/05 3235197 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=sas3r05g.pdf Serial Attached SCSI - 3 (SAS-3) (Editor: Alvin Cox) Rev: 05g Uploaded: 2013/09/05 50111018 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=sas3r05g.zip SCSI Block Commands - 3 (SBC-3) (Editor: George Penokie) Rev: 35h Uploaded: 2013/09/04 3108689 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r35h.pdf SCSI over PCIe(r) architecture (SOP) (Editor: Curtis Stevens) Rev: 04d Uploaded: 2013/09/02 2053004 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=sop-r04d.pdf (Report generated on 2013/09/08 at 00:01:29) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From mickey.felton at emc.com Mon Sep 9 10:25:38 2013 From: mickey.felton at emc.com (Felton, Mickey) Date: Mon, 9 Sep 2013 17:25:38 +0000 Subject: Some items to discuss for your stay in Boston area Message-ID: Formatted message: HTML-formatted message Dear September T10 Guests: Welcome to Boston! A few items for your arrival and stay at the hotel: 1. The internet has 2 options for Speed, your stay includes PREMIUM internet, the highest speed offered. Please select that option (which has an added cost) and it would be removed from your bill at the end of your stay. 2. We will do our best to keep the itemizations OFF the bill and OFF the credit card bill, but PLEASE examine both before you leave to make sure the itemizations are removed to make your accounting easier. 3. A hot item in the morning breakfast is being added this year, and lunch will be served at 12:30 every day with the menu as follows: a. Tex mex buffet b. Pizza buffet c. Fish & Chowder & chicken Buffet d. Italian Buffet 4. Outside the hotel, food choices have changed a lot in the last 3 years, I've update the list below with the favorites, as always Yelp tells you the basics, but these below are the highly recommended restaurants by many people. WEST OF HOTEL: Best Seafood: Sole Proprietor, 118 Highland Street, about 25 minute drive but VERY worth it!, RT 9 west for 12miles(take fork right), into Worcester, on right side. Best Steak houses Willys steakhouse, 2 grafton street, RT9 west towards Worcester about 6 miles, take RT 140 north about 3 miles, at the lights its on the left side.(20 min drive) 111 Steakhouse, 111 Shrewsbury street, Rt 9 west to Worcester, take left at fork to shrewsury street, down another 1 mile on left.(25 minute drive) Best OLD SCHOOL Hot dog: Coney island hot dog 158 Southbridge St Worcester, MA 01608 Phone number (508) 753-4362 Best Italian: Arturo's Ristorante, 50 East Main Street, Westborough, MA (Take Rt 9 west, to Rt 30 west, go 1 mile, on the right in mini-mall) Best IRISH: O-connor's 1160 W Boylston St, Worcester, MA 01606 Phone number (508) 853-0789 Best Burger (Cow or BISON!): Teds Montana Grill, 400 Union Street, Westborough, MA (Take Rt 9 west, to Rt 30 west, go 1 mile, on the left deep in the plaza) Best ridiculous oversize SUB: Rigatta Deli, 3 Colonial Drive, (Take Rt 9 west, to Rt 30 west, go 1 mile, on the right deep in the plaza) Dunkin donuts is out front. EAST OF HOTEL There is only one area to go, which is Framingham/Natick Area, which is also the shopping district about 20 minutes EAST on RT 9. Restaurants in this area that are better than the others: On right side in order: British Beer, awesome beef sandwiches, and apps.. Legal Seafoods Minado on right side, across from BIGGER NATICK mall, all you can SUSHI On Left side in order Ken's steakhouse (the original!) John Harvards beer works (in strip mall, in way back) Standard chain eats: Olive Garden, Chinese, Fridays, Uno's, Tai, Subs, etc.. From pooja.gupta at synopsys.com Tue Sep 10 02:19:39 2013 From: pooja.gupta at synopsys.com (Pooja Gupta) Date: Tue, 10 Sep 2013 09:19:39 +0000 Subject: Doubt in SAS speed negotiation sequence Message-ID: Formatted message: HTML-formatted message Attachment #1: image001.png Hi, Section 5.10.4.2.4 "SAS speed negotiation sequence" of SPL-3 (Revision 02, 16 January 2013) describes SAS Speed Negotiation sequence as: [cid:image001.png at 01CEAE29.B275A670] Here, I am not able to understand the difference between the two yellow Diamond decision boxes. I feel that, both result in the same condition of SNW-1 being valid and SNW-2 being invalid. Can you please help me understand this. Regards, Pooja From alvin.cox at seagate.com Tue Sep 10 13:34:54 2013 From: alvin.cox at seagate.com (Alvin Cox) Date: Tue, 10 Sep 2013 15:34:54 -0500 Subject: SAS PHY teleconference: Thursday, September 12, 2013, 10:00 am CDT Message-ID: Formatted message: HTML-formatted message Agenda: Status of SAS3_EYEOPENING sip file. Editorial changes to the standard. Additional topics. Topic: SAS-3 Date: Thursday, September 12, 2013 Time: 10:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 827 988 093 Meeting Password: sas12gbps ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://seagate.webex.com/seagate/j.php?ED=158650437&UID=0&PW=NODQzMjNhYTdm&R T=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: sas12gbps 4. Click "Join". To view in other time zones or languages, please click the link: https://seagate.webex.com/seagate/j.php?ED=158650437&UID=0&PW=NODQzMjNhYTdm&O RT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- 1. Provide your number when you join the meeting to receive a call back. Alternatively, you can call one of the following numbers: SeaTel: 8-844-1000 United States: 1-952-230-1270 US Toll-Free: 1-855-856-8765 Singapore: 65-6485-3969 China-Beijing: 86-10-5875-1983 China-Shanghai: 86-21-6141-6283 China-Shenzhen: 86-755-2547-1583 China-Suzhou: 86-512-6273-5995 China-Wuxi: 86-510-8527-3993 Korea-Suwon: 82-31-8025-6006 Malaysia-Penang: 60-4-291-3598 Malaysia-Johore: 60-7-555-6767 Thailand-Teparuk: 66-2-715-7878 Thailand-Korat: 66-44-703599 Taiwan-Taipei: 886-2-2514-2211 2. Follow the instructions that you hear on the phone. Your Cisco Unified MeetingPlace meeting ID: 827 988 093 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://seagate.webex.com/seagate/mc 2. On the left navigation bar, click "Support". To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://seagate.webex.com/seagate/j.php?ED=158650437&UID=0&ICS=MRS2&LD=1&RD=2 &ST=1&SHA2=pEI2tL0j5oE58s9ytOQWHuV98SACdVZgiFnrG-CNDds=&RT=MiM3 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://seagate.webex.com/seagate/meetingcenter/mcsetup.php http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. -- Alvin Cox Seagate Technology, LLC Cell 405-206-4809 Office 405-392-3738 E-Mail alvin.cox at seagate.com From pooja.gupta at synopsys.com Tue Sep 10 22:24:05 2013 From: pooja.gupta at synopsys.com (Pooja Gupta) Date: Wed, 11 Sep 2013 05:24:05 +0000 Subject: Issues in Figures on SAS Speed Negotiation Sequence Message-ID: Formatted message: HTML-formatted message Hi, Figure 79 - SAS speed negotiation sequence - phy reset problem in Train_Rx-SNW of SPL-3 (Revision 02, 16 January 2013) Shows SAS speed negotiation sequence for a case where there is a problem in Train_Rx-SNW . Here, I see two issues in the figure as mentioned below: 1. As per new spec, in SNW-3 we can have Train_Rx-SNW and Train_Tx-SNW. There is nothing like Train-SNW and Figure title also mentions it as : Train_Rx-SNW. So, I think this needs a correction 2. In SNW-3 after Phy capabilities are exchanged, after RCDT, MTT is written. There is no such timer as MTT defined in spec. For Train_Rx-SNW, it should be MRTT. Similar corrections are required in Figure 80 on Page 192 for: Train-SNW and MTT. In addition, in Figure 80, colors mentioned at the bottom and used in the figure are not correct for TRAIN pattern and TRAIN_DONE pattern. Please share your opinion on this. Regards, Pooja From gerry.houlder at seagate.com Wed Sep 11 12:44:44 2013 From: gerry.houlder at seagate.com (Gerry Houlder) Date: Wed, 11 Sep 2013 14:44:44 -0500 Subject: Agenda for SMR study group meeting Sept. 19 Message-ID: Formatted message: HTML-formatted message The agenda for the Sept. 19 SMR study group meeting (held after the Plenary meeting) will be as follows: 1) Review SMR slides that will be presented at Sept. 18-20 and Oct. 31-23 Linux conferences. A PDF of this presentation will be posted no later than Sept. 18. 2) Discuss next steps towards standardizing the new functions needed 3) Plans for November SMR study group meeting a) Discuss feedback received from the Linux conference presentations From Ralph.Weber at wdc.com Thu Sep 12 05:07:06 2013 From: Ralph.Weber at wdc.com (Ralph Weber) Date: Thu, 12 Sep 2013 12:07:06 +0000 Subject: New SPC-4 Letter Ballot documents uploaded Message-ID: Formatted message: HTML-formatted message The latest SPC-4 Letter Ballot comment database is available in printable format as: http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-311r7.pdf Pages 1 and 2 of this file explain how to use the other files mentioned in this message. Those unfamiliar with SPC-4 Letter Ballot files should begin by reading these pages, since only superficial information is provided here. For reasons which defy explanation, the Letter Ballot r7 Fickle Finger of Fate fell on MAM. All comments were processed for all MAM-related subclauses (model, read/write attribute, parameter data formats). At the top of page 4 in 12-311r7 there is a lengthy list of MAM-related comments to be resolved by the Westborough CAP. To see what the comments processing hath wrought, download: http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36i.pdf The latest FDF version of the SPC-4 Letter Ballot comments database is: http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-311r7.fdf Use of the FDF file will require a copy of SPC-4 r36, which can be obtained from: http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36.pdf See you in Massachusetts, .Ralph From kdbutt at us.ibm.com Thu Sep 12 15:17:56 2013 From: kdbutt at us.ibm.com (Kevin D Butt) Date: Thu, 12 Sep 2013 15:17:56 -0700 Subject: Additional sense code for humidity Message-ID: Formatted message: HTML-formatted message Ralph and all, We have an additional sense code for WARNING - SPECIFIED TEMPERATURE EXCEEDED but nothing for humidity. Could we add a WARNING - HUMIDITY OUT OF BOUNDS additional sense code? Thanks, Kevin D. Butt SCSI Architect, Tape Firmware, T10 Standards Data Protection & Retention MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744 Tel: 520-799-5280 Fax: 520-799-2723 (T/L:321) Email address: kdbutt at us.ibm.com From mickey.felton at emc.com Fri Sep 13 06:40:54 2013 From: mickey.felton at emc.com (Felton, Mickey) Date: Fri, 13 Sep 2013 13:40:54 +0000 Subject: Some items to discuss for your stay in Boston area Message-ID: Formatted message: HTML-formatted message Sorry one more change to the schedule: All CHANDLER meetings are now moved to AUTUMN conference rooms. (2013/09/12 Version) Monday 9/16 9 10 11 12 1 2 3 4 5 6 7 8 +=======================================+ Chandler | CAP WG | Dinner | (All) +--------+ Wednesday 9/18 9 10 11 12 1 2 3 4 5 6 7 8 9 +=======================+===========+ Chandler |Joint Phy/SAS Protocolhttp://www.t10.org/ftp/t10/sop-agnd.htm>|lunch|T10 Plen Formatted message: HTML-formatted message I have uploaded SOP rev 4e. This document completes the incorporation of letter ballot comments and all associated proposals. Please look this over for review on Wednesday next week. ------------------------------------------------- Curtis E. Stevens Director, Standards & Features Technology 3355 Michelson Dr. #100 Office: 1-1041 Irvine, Ca. 92612 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: Curtis.Stevens at WDC.com Remember, you may only be blamed for something if you are actually doing something. From lohmeyer at t10.org Sat Sep 14 23:01:30 2013 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 15 Sep 2013 00:01:30 -0600 Subject: Recent T10 documents uploaded since 2013/09/08 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SPC-4 Letter Ballot Comment Resolutions (by: Ralph Weber) T10/12-311r7 Uploaded: 2013/09/12 8572039 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-311r7.fdf SPC-4 Letter Ballot Comment Resolutions (by: Ralph Weber) T10/12-311r7 Uploaded: 2013/09/12 2438499 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-311r7.pdf SAS3-PHY: SAS3_EYEOPENING script release (by: Graeme Boyd, Rod Zavari) T10/13-018r4 Uploaded: 2013/09/12 290808 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-018r4.pdf SAS3-PHY: SAS3_EYEOPENING script release (by: Graeme Boyd, Rod Zavari) T10/13-018r4 Uploaded: 2013/09/12 54086102 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-018r4.zip SOP Letter Ballot Comments (by: Curtis Stevens) T10/13-108r3 Uploaded: 2013/09/13 5203744 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-108r3.fdf SOP Letter Ballot Comments (by: Curtis Stevens) T10/13-108r3 Uploaded: 2013/09/13 10172598 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-108r3.pdf SPL-3 Credit Advance (by: Greg Tabor, Tim Symons) T10/13-138r0 Uploaded: 2013/09/12 340247 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-138r0.pdf SAS-3 Rx Stressed Eye Simulation (by: Harvey Newman) T10/13-224r0 Uploaded: 2013/09/12 1174242 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-224r0.pdf SPL-4: 128b130b Coding (by: George Penokie) T10/13-225r0 Uploaded: 2013/09/11 135104 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-225r0.pdf SMR Presentation (by: Curtis Stevens, Gerry Houlder, Jorge Campello) T10/13-229r0 Uploaded: 2013/09/12 342610 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-229r0.pdf SPL-3 RRDY, EXTENDED CONNECTION (by: Tim Symons) T10/13-230r0 Uploaded: 2013/09/12 183859 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-230r0.pdf SAS-4 / SPL-4 Block encoding discussion topics (by: Tim Symons) T10/13-232r0 Uploaded: 2013/09/13 608765 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-232r0.pdf Working Drafts -------------- SCSI over PCIe(r) architecture (SOP) (Editor: Curtis Stevens) Rev: 04e Uploaded: 2013/09/13 2112881 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=sop-r04e.pdf SCSI Primary Commands - 4 (SPC-4) (Editor: Ralph Weber) Rev: 36i Uploaded: 2013/09/12 4418892 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36i.pdf (Report generated on 2013/09/15 at 00:01:30) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From curtis.stevens at wdc.com Tue Sep 17 08:05:35 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Tue, 17 Sep 2013 15:05:35 +0000 Subject: SOPQI WG Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-3496-3.txt 17-Sep Please note that the conference bridge has changed. Date: 23-Sep-2013, Time: 12:30-2:30 Pacific Time Meeting to focus on SOP Curtis Stevens invites you to an online meeting using WebEx. Meeting Number: 743 216 404 Meeting Password: This meeting does not require a password. ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://premconf.webex.com/premconf/j.php?J=743216404 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: This meeting does not require a password. 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll-free number (Premiere): 1-888-757-2790 (US/Canada) Call-in number (Premiere): 1-719-359-9722 (US/Canada) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6831898120&num=1888-757 -2790&num2=1719-359-9722 Attendee access code: 683 189 8120 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From George.Penokie at lsi.com Tue Sep 17 08:06:37 2013 From: George.Penokie at lsi.com (Penokie, George) Date: Tue, 17 Sep 2013 09:06:37 -0600 Subject: SBC-3 letter ballot comments relating to 13-213 Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-3496-6.txt When: Tuesday, October 15, 2013 3:00 PM-5:00 PM (GMT-06:00) Central Time (US & Canada). Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* George Penokie invites you to an online meeting using WebEx. Meeting Number: 800 853 607 Meeting Password: scsiata Attendee ID: You must join WebEx from a PC for your Attendee ID Number. If you are unable to join WebEx, simply press the # (hash) key to bypass the Attendee ID Number. For additional Toll and Toll Free numbers click here: http://mpnumbers.lsi.com ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://lsi-corp.webex.com/lsi-corp/j.php?J=800853607&PW=NZjVkMTM2MzEz 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: scsiata 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Audio conference information ------------------------------------------------------- 1. Please call one of the following numbers: CA, San Jose Local and USA Mobile Phone: 408-433-6100 Use From Any LSI Office: 18-8000 CO, Colorado Springs (Local): 719-533-7100 CO, Fort Collins (Local): 970-206-6100 CO, Longmont (Local): 720-864-4100 GA, Norcross (Local): 678-728-9700 KS, Wichita (Local): 316-201-2060 MN, Mendota Heights (Local): 952-921-8400 MN, Rochester (Local): 507-328-8990 OR, Beaverton (Local): 503-495-2380 PA, Allentown (Local): 610-712-6100 TX, Austin (Local): 512-821-6700 TX, Houston (Local): 281-379-7810 West Coast (Toll Free): 1-866-822-0330 East Coast (Toll Free): 1-877-574-5644 China (Toll Free): 800-820-5902 Europe (Toll Free): 00-800-5742-6777 India (Toll Free): 000-800-1091188 Japan (Local): 81-3-5463-7122 Singapore (Local): 65-6818-5678 Taiwan (Local): 886-2-8722-3333 2. Follow the instructions that you hear on the phone. Your Cisco Unified MeetingPlace meeting ID: 800 853 607 For additional Toll and Toll Free numbers click here: http://mpnumbers.lsi.com http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From curtis.stevens at wdc.com Tue Sep 17 08:11:18 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Tue, 17 Sep 2013 15:11:18 +0000 Subject: SOPQI WG Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-2440-3.txt 17-Sep Please note that the conference bridge has changed. Date: 7-Oct-2013, Time: 12:30-2:30 Pacific Time Meeting to focus on SOP Curtis Stevens invites you to an online meeting using WebEx. Meeting Number: 745 009 558 Meeting Password: This meeting does not require a password. ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://premconf.webex.com/premconf/j.php?J=745009558 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: This meeting does not require a password. 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll-free number (Premiere): 1-888-757-2790 (US/Canada) Call-in number (Premiere): 1-719-359-9722 (US/Canada) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6831898120&num=1888-757 -2790&num2=1719-359-9722 Attendee access code: 683 189 8120 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From curtis.stevens at wdc.com Tue Sep 17 08:11:58 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Tue, 17 Sep 2013 15:11:58 +0000 Subject: SOPQI WG Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-2440-6.txt 17-Sep Please note that the conference bridge has changed. Date: 23-Sep-2013, Time: 12:30-2:30 Pacific Time Meeting to focus on SOP Curtis Stevens invites you to an online meeting using WebEx. Meeting Number: 743 216 404 Meeting Password: This meeting does not require a password. ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://premconf.webex.com/premconf/j.php?J=743216404 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: This meeting does not require a password. 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll-free number (Premiere): 1-888-757-2790 (US/Canada) Call-in number (Premiere): 1-719-359-9722 (US/Canada) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6831898120&num=1888-757 -2790&num2=1719-359-9722 Attendee access code: 683 189 8120 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From curtis.stevens at wdc.com Tue Sep 17 08:15:08 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Tue, 17 Sep 2013 15:15:08 +0000 Subject: SOPQI WG Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-1544-3.txt 17-Sep Please note that the conference bridge has changed. Date: 23-Sep-2013, Time: 12:30-2:30 Pacific Time Meeting to focus on SOP Curtis Stevens invites you to an online meeting using WebEx. Meeting Number: 743 216 404 Meeting Password: This meeting does not require a password. ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://premconf.webex.com/premconf/j.php?J=743216404 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: This meeting does not require a password. 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll-free number (Premiere): 1-888-757-2790 (US/Canada) Call-in number (Premiere): 1-719-359-9722 (US/Canada) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6831898120&num=1888-757 -2790&num2=1719-359-9722 Attendee access code: 683 189 8120 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From curtis.stevens at wdc.com Tue Sep 17 08:19:39 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Tue, 17 Sep 2013 15:19:39 +0000 Subject: SOPQI WG Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-1544-6.txt 17-Sep Please note that the conference bridge has changed. Date: 28-Oct-2013, Time: 12:30-2:30 Pacific Time Meeting to focus on SOP Curtis Stevens invites you to an online meeting using WebEx. Meeting Number: 741 530 734 Meeting Password: This meeting does not require a password. ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://premconf.webex.com/premconf/j.php?J=741530734 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: This meeting does not require a password. 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll-free number (Premiere): 1-888-757-2790 (US/Canada) Call-in number (Premiere): 1-719-359-9722 (US/Canada) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6831898120&num=1888-757 -2790&num2=1719-359-9722 Attendee access code: 683 189 8120 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From curtis.stevens at wdc.com Tue Sep 17 08:16:07 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Tue, 17 Sep 2013 15:16:07 +0000 Subject: SOPQI WG Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-1544-9.txt 17-Sep Please note that the conference bridge has changed. Date: 14-Oct-2013, Time: 12:30-2:30 Pacific Time Meeting to focus on SOP Curtis Stevens invites you to an online meeting using WebEx. Meeting Number: 745 052 366 Meeting Password: This meeting does not require a password. ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://premconf.webex.com/premconf/j.php?J=745052366 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: This meeting does not require a password. 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll-free number (Premiere): 1-888-757-2790 (US/Canada) Call-in number (Premiere): 1-719-359-9722 (US/Canada) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6831898120&num=1888-757 -2790&num2=1719-359-9722 Attendee access code: 683 189 8120 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From curtis.stevens at wdc.com Tue Sep 17 08:14:16 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Tue, 17 Sep 2013 15:14:16 +0000 Subject: SOPQI WG Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-1544-12.txt 17-Sep Please note that the conference bridge has changed. Date: 14-Oct-2013, Time: 12:30-2:30 Pacific Time Meeting to focus on SOP From George.Penokie at lsi.com Tue Sep 17 10:59:24 2013 From: George.Penokie at lsi.com (Penokie, George) Date: Tue, 17 Sep 2013 11:59:24 -0600 Subject: Issues in Figures on SAS Speed Negotiation Sequence Message-ID: Formatted message: HTML-formatted message Pooja, You need to look at the current version of SPL-3 which is revision 4 as some of your comments have already been fixed. However, MTT is still not correct in revision 4. I will correct that in the next revision. Bye for now, George Penokie LSI Corporation 3033 41 St NW Rochester , MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pooja Gupta Sent: Wednesday, September 11, 2013 12:24 AM To: t10 at t10.org Subject: Issues in Figures on SAS Speed Negotiation Sequence Hi, Figure 79 - SAS speed negotiation sequence - phy reset problem in Train_Rx-SNW of SPL-3 (Revision 02, 16 January 2013) Shows SAS speed negotiation sequence for a case where there is a problem in Train_Rx-SNW . Here, I see two issues in the figure as mentioned below: 1. As per new spec, in SNW-3 we can have Train_Rx-SNW and Train_Tx-SNW. There is nothing like Train-SNW and Figure title also mentions it as : Train_Rx-SNW. So, I think this needs a correction 2. In SNW-3 after Phy capabilities are exchanged, after RCDT, MTT is written. There is no such timer as MTT defined in spec. For Train_Rx-SNW, it should be MRTT. Similar corrections are required in Figure 80 on Page 192 for: Train-SNW and MTT. In addition, in Figure 80, colors mentioned at the bottom and used in the figure are not correct for TRAIN pattern and TRAIN_DONE pattern. Please share your opinion on this. Regards, Pooja From George.Penokie at lsi.com Tue Sep 17 11:41:58 2013 From: George.Penokie at lsi.com (Penokie, George) Date: Tue, 17 Sep 2013 12:41:58 -0600 Subject: Doubt in SAS speed negotiation sequence Message-ID: Formatted message: HTML-formatted message Attachment #1: image001.png Pooja, The flow chart is correct. After the device goes through SNW-1 and SNW-2 there are three possible outcomes: go to Final-SNW, go to SNW-3, or end the speed negotiation . 1- If the SNW-1 negotiation was valid and the SNW-2 negotiation failed. That means the agreed to speed is 1.5 Gbps and the Final-SNW occurs. 2- Any other combination requires another decision to decide what should happen next. 3- This decision is not based on if a negotiation failed or was successful it is based on whether any negotiation occurred or did not occur. a. if there was no SNW-1 negotiation and there was a SNW-2 negotiation then the phy ends the speed negotiation sequence without progressing to SNW-3, transmits negotiation idle, and ignores the SNW information received during SNW-3. b. If there was a SNW-1 negotiation and there was a SNW-2 negotiation then the phy moves to SNW-3 c. If there was a SNW-1 negotiation and there was a no SNW-2 negotiation then the phy moves to SNW-3 d. there was no SNW-1 negotiation and there was a no SNW-2 negotiation then the phy moves to SNW-3 Bye for now, George Penokie LSI Corporation 3033 41 St NW Rochester , MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pooja Gupta Sent: Tuesday, September 10, 2013 4:20 AM To: t10 at t10.org Subject: Doubt in SAS speed negotiation sequence Hi, Section 5.10.4.2.4 "SAS speed negotiation sequence" of SPL-3 (Revision 02, 16 January 2013) describes SAS Speed Negotiation sequence as: [cid:image001.png at 01CEB3A8.CEC5A4E0] Here, I am not able to understand the difference between the two yellow Diamond decision boxes. I feel that, both result in the same condition of SNW-1 being valid and SNW-2 being invalid. Can you please help me understand this. Regards, Pooja From curtis.stevens at wdc.com Tue Sep 17 12:19:15 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Tue, 17 Sep 2013 19:19:15 +0000 Subject: SOPQI WG & Atomic Write Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-1780-3.txt 17-Sep Atomic Write portion starts at 2:30 Pacific Time 17-Sep Please note that the conference bridge has changed. Date: 14-Oct-2013, Time: 12:30-2:30 Pacific Time 12:30-2:30 Meeting to focus on SOP 2:30-3:30 Meeting to focus on Atomic Write Curtis Stevens invites you to an online meeting using WebEx. Meeting Number: 745 052 366 Meeting Password: This meeting does not require a password. ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://premconf.webex.com/premconf/j.php?J=745052366 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: This meeting does not require a password. 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll-free number (Premiere): 1-888-757-2790 (US/Canada) Call-in number (Premiere): 1-719-359-9722 (US/Canada) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6831898120&num=1888-757 -2790&num2=1719-359-9722 Attendee access code: 683 189 8120 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From pooja.gupta at synopsys.com Tue Sep 17 23:12:10 2013 From: pooja.gupta at synopsys.com (Pooja Gupta) Date: Wed, 18 Sep 2013 06:12:10 +0000 Subject: Issues in Figures on SAS Speed Negotiation Sequence Message-ID: Formatted message: HTML-formatted message Thanks George for the reply. You are correct that Train-SNW has been replaced by Train_Rx-SNW in revision 4 of SPL-3. But two issues still remain: 1. MTT to be replaced by MRTT which you have already acknowledged. 2. Colors used in Figure 80 for First Train_Rx-SNW and Second Train_Rx-SNW are those of ALIGN(0) and ALIGN (1) Instead of TRAIN pattern and TRAIN_DONE pattern Regards, Pooja From: Penokie, George [mailto:George.Penokie at lsi.com] Sent: Tuesday, September 17, 2013 11:29 PM To: Pooja Gupta; t10 at t10.org Subject: RE: Issues in Figures on SAS Speed Negotiation Sequence Pooja, You need to look at the current version of SPL-3 which is revision 4 as some of your comments have already been fixed. However, MTT is still not correct in revision 4. I will correct that in the next revision. Bye for now, George Penokie LSI Corporation 3033 41 St NW Rochester , MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pooja Gupta Sent: Wednesday, September 11, 2013 12:24 AM To: t10 at t10.org Subject: Issues in Figures on SAS Speed Negotiation Sequence Hi, Figure 79 - SAS speed negotiation sequence - phy reset problem in Train_Rx-SNW of SPL-3 (Revision 02, 16 January 2013) Shows SAS speed negotiation sequence for a case where there is a problem in Train_Rx-SNW . Here, I see two issues in the figure as mentioned below: 1. As per new spec, in SNW-3 we can have Train_Rx-SNW and Train_Tx-SNW. There is nothing like Train-SNW and Figure title also mentions it as : Train_Rx-SNW. So, I think this needs a correction 2. In SNW-3 after Phy capabilities are exchanged, after RCDT, MTT is written. There is no such timer as MTT defined in spec. For Train_Rx-SNW, it should be MRTT. Similar corrections are required in Figure 80 on Page 192 for: Train-SNW and MTT. In addition, in Figure 80, colors mentioned at the bottom and used in the figure are not correct for TRAIN pattern and TRAIN_DONE pattern. Please share your opinion on this. Regards, Pooja From alvin.cox at seagate.com Wed Sep 18 04:55:48 2013 From: alvin.cox at seagate.com (Alvin Cox) Date: Wed, 18 Sep 2013 06:55:48 -0500 Subject: SAS PHY teleconference, Thursday, October 10, 2013, 10:00 am CDT Message-ID: Formatted message: HTML-formatted message Next call October 10, 2013, 10:00 am, Central Daylight Time Agenda: 1. Review of pulse response value changes (see 13-240r0 Formatted message: HTML-formatted message Pooja, The colors will also be fixed in the next revision. Bye for now, George Penokie LSI Corporation 3033 41 St NW Rochester , MN 55901 507-328-9017 george.penokie at lsi.com From: Pooja Gupta [mailto:pooja.gupta at synopsys.com] Sent: Wednesday, September 18, 2013 1:12 AM To: Penokie, George; t10 at t10.org Subject: RE: Issues in Figures on SAS Speed Negotiation Sequence Thanks George for the reply. You are correct that Train-SNW has been replaced by Train_Rx-SNW in revision 4 of SPL-3. But two issues still remain: 1. MTT to be replaced by MRTT which you have already acknowledged. 2. Colors used in Figure 80 for First Train_Rx-SNW and Second Train_Rx-SNW are those of ALIGN(0) and ALIGN (1) Instead of TRAIN pattern and TRAIN_DONE pattern Regards, Pooja From: Penokie, George [mailto:George.Penokie at lsi.com] Sent: Tuesday, September 17, 2013 11:29 PM To: Pooja Gupta; t10 at t10.org Subject: RE: Issues in Figures on SAS Speed Negotiation Sequence Pooja, You need to look at the current version of SPL-3 which is revision 4 as some of your comments have already been fixed. However, MTT is still not correct in revision 4. I will correct that in the next revision. Bye for now, George Penokie LSI Corporation 3033 41 St NW Rochester , MN 55901 507-328-9017 george.penokie at lsi.com From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Pooja Gupta Sent: Wednesday, September 11, 2013 12:24 AM To: t10 at t10.org Subject: Issues in Figures on SAS Speed Negotiation Sequence Hi, Figure 79 - SAS speed negotiation sequence - phy reset problem in Train_Rx-SNW of SPL-3 (Revision 02, 16 January 2013) Shows SAS speed negotiation sequence for a case where there is a problem in Train_Rx-SNW . Here, I see two issues in the figure as mentioned below: 1. As per new spec, in SNW-3 we can have Train_Rx-SNW and Train_Tx-SNW. There is nothing like Train-SNW and Figure title also mentions it as : Train_Rx-SNW. So, I think this needs a correction 2. In SNW-3 after Phy capabilities are exchanged, after RCDT, MTT is written. There is no such timer as MTT defined in spec. For Train_Rx-SNW, it should be MRTT. Similar corrections are required in Figure 80 on Page 192 for: Train-SNW and MTT. In addition, in Figure 80, colors mentioned at the bottom and used in the figure are not correct for TRAIN pattern and TRAIN_DONE pattern. Please share your opinion on this. Regards, Pooja From George.Penokie at lsi.com Wed Sep 18 09:35:12 2013 From: George.Penokie at lsi.com (Penokie, George) Date: Wed, 18 Sep 2013 10:35:12 -0600 Subject: Review of 13-138 SPL-3 Credit Advance Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-4092-3.txt When: Tuesday, October 29, 2013 3:00 PM-5:00 PM (GMT-06:00) Central Time (US & Canada). Note: The GMT offset above does not reflect daylight saving time adjustments. *~*~*~*~*~*~*~*~*~* George Penokie invites you to an online meeting using WebEx. Meeting Number: 806 607 744 Meeting Password: scsiata Attendee ID: You must join WebEx from a PC for your Attendee ID Number. If you are unable to join WebEx, simply press the # (hash) key to bypass the Attendee ID Number. For additional Toll and Toll Free numbers click here: http://mpnumbers.lsi.com ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://lsi-corp.webex.com/lsi-corp/j.php?J=806607744&PW=NZmNjMjNhMDdk 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: scsiata 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Audio conference information ------------------------------------------------------- 1. Please call one of the following numbers: CA, San Jose Local and USA Mobile Phone: 408-433-6100 Use From Any LSI Office: 18-8000 CO, Colorado Springs (Local): 719-533-7100 CO, Fort Collins (Local): 970-206-6100 CO, Longmont (Local): 720-864-4100 GA, Norcross (Local): 678-728-9700 KS, Wichita (Local): 316-201-2060 MN, Mendota Heights (Local): 952-921-8400 MN, Rochester (Local): 507-328-8990 OR, Beaverton (Local): 503-495-2380 PA, Allentown (Local): 610-712-6100 TX, Austin (Local): 512-821-6700 TX, Houston (Local): 281-379-7810 West Coast (Toll Free): 1-866-822-0330 East Coast (Toll Free): 1-877-574-5644 China (Toll Free): 800-820-5902 Europe (Toll Free): 00-800-5742-6777 India (Toll Free): 000-800-1091188 Japan (Local): 81-3-5463-7122 Singapore (Local): 65-6818-5678 Taiwan (Local): 886-2-8722-3333 2. Follow the instructions that you hear on the phone. Your Cisco Unified MeetingPlace meeting ID: 806 607 744 For additional Toll and Toll Free numbers click here: http://mpnumbers.lsi.com http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From lohmeyer at t10.org Wed Sep 18 09:25:51 2013 From: lohmeyer at t10.org (John Lohmeyer) Date: Wed, 18 Sep 2013 10:25:51 -0600 Subject: draft CAP minutes are posted Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * John Lohmeyer * The draft CAP working group minutes are available at: http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-226r0.htm -- John Lohmeyer Email: lohmeyer at t10.org LSI Corp. Voice: +1-719-533-7560 4420 ArrowsWest Dr. Cell: +1-719-338-1642 Colo Spgs, CO 80907 * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From lohmeyer at t10.org Wed Sep 18 10:15:43 2013 From: lohmeyer at t10.org (John Lohmeyer) Date: Wed, 18 Sep 2013 11:15:43 -0600 Subject: draft SAS PHY/Protocol minutes are posted Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * John Lohmeyer * The draft SAS PHY/Protocol working group minutes are available at: http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-227r0.htm -- John Lohmeyer Email: lohmeyer at t10.org LSI Corp. Voice: +1-719-533-7560 4420 ArrowsWest Dr. Cell: +1-719-338-1642 Colo Spgs, CO 80907 * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From George.Penokie at lsi.com Thu Sep 19 07:53:28 2013 From: George.Penokie at lsi.com (Penokie, George) Date: Thu, 19 Sep 2013 08:53:28 -0600 Subject: Typo in latest spec SPL3R04 for Persistent Connections - 1 message with two sources Message-ID: Formatted message: HTML-formatted message Craig, Persistent Connection () is not a message it is a confirmation that is sent to the port layer. There are many confirmations that are same that come from different states and state machines that are the same. As for the Persistent Connection () confirmation here is the issue that adding it to the SL_CC2:Connected state from proposal 13-158. There are two cases in where the initial EXTEND_CONNECTION from the target could get lost or corrupted that would cause the handshake to not complete. a) If the target's EM1 receives a Persistent Connection (Transmit) the target will transmit the EXTEND_CONNECTION and then wait for an EXTEND_CONNECTION to be received. If the EXTEND_CONNECTION is never received, then EM1 never sends a Persistent Connection Established (Enable) to the port layer and there is no transition out of EM1. Assuming the port layer does not initialize to the persistent connection being enabled then it should have the persistent connection disabled. b) If the initiator's EM1 receives a Persistent Connection (Wait) the initiator will wait unit it gets the EXTEND_CONNECTION. When the EXTEND_CONNECTION is received the initiator will transmit an EXTEND_CONNECTION and send a Persistent Connection Established (Enable) to the port layer. At that point there is also a transition to EM2. If, for some reason, the target never receives the EXTEND_CONNECTION its EM1 will never send an Persistent Connection Established (Enable) to the port layer nor will there be a transition to its EM2. The result is the target will not send any EXTEND_CONNECTIONs. This will cause the initiator's EM2 to timeout resulting in a an Persistent Connection Established (Disable) to the port layer. So assuming the port layer defaults to persistent connections disabled there should be no hangs. However, one should never make assumptions about the creativity of those reading standards. Bye for now, George Penokie LSI Corporation 3033 41 St NW Rochester , MN 55901 507-328-9017 george.penokie at lsi.com From: Craig Stoops [mailto:Craig.Stoops at synopsys.com] Sent: Wednesday, September 18, 2013 8:26 PM To: Penokie, George; t10 at t10.org Cc: Voorhees, Bill Subject: Typo in latest spec SPL3R04 for Persistent Connections - 1 message with two sources Hi George, It was brought to my attention that in the SPL3R04 that the some new language was added to the SLCC however the message is now generated by both the SLCC and the EM. Previous proposals only have the message coming from the EM. The SLCC sends the Persistent Connection () message to the EM, and the EM does the rest. The PL should be assuming that unless it has received a message from the EM, that no PC has been established. So the need for the SLCC to send "disabled" is not needed, it's obvious that no PC has been enabled as far as the PL is concerned on a new connection. Most importantly though, there should only be 1 source of the message, and I believe the proposals were correct that it should come from the EM. The source should the solely the EM or solely the SLCC, not a mix. There is no other messages in the architecture that have two sources. Craig 6.16.4.5.1 State description a) an Extend Connection (Transmit) argument, then this state shall: A) send a Persistent Connection (Transmit) message to the SSP_EM link layer state machine (see 6.18.9.12); and B) send a Persistent Connection Established (Disabled) confirmation to the port layer.; b) an Extend Connection (Wait) argument, then this state shall: A) send a Persistent Connection (Wait) message to the SSP_EM link layer state machine (see 6.18.9.12); and B) send a Persistent Connection Established (Disabled) confirmation to the port layer; 6.18.9.12.2 SSP_EM1:Establish state This state establishes a persistent connection (see 6.18.1). If this state receives a Persistent Connection (Transmit) message, then this state: a) shall send a Transmit EXTEND_CONNECTION message to the SSP transmitter; and b) if this state receives an EXTEND_CONNECTION Received message, then this state shall send a Persistent Connection Established (Enabled) confirmation to the port layer. If this state receives a Persistent Connection (Wait) message and receives an EXTEND_CONNECTION Received message, then this state shall: a) send a Transmit EXTEND_CONNECTION message to the SSP transmitter; and b) send a Persistent Connection Established (Enabled) confirmation to the port layer. If this state receives a Persistent Connection (Off) message, then this state shall: a) ignore EXTEND_CONNECTION Received messages; and b) send a Persistent Connection Established (Disabled) confirmation to the port layer. From George.Penokie at lsi.com Thu Sep 19 09:16:07 2013 From: George.Penokie at lsi.com (Penokie, George) Date: Thu, 19 Sep 2013 10:16:07 -0600 Subject: Typo in latest spec SPL3R04 for Persistent Connections - 1 message with two sources Message-ID: Formatted message: HTML-formatted message Craig, The Frame Transmitted confirmation may originate from the SMP_IP2:Transmit_Frame state or the SSP_TF3:Transmit_Frame state. Bye for now, George Penokie LSI Corporation 3033 41 St NW Rochester , MN 55901 507-328-9017 george.penokie at lsi.com From: Craig Stoops [mailto:Craig.Stoops at synopsys.com] Sent: Thursday, September 19, 2013 10:26 AM To: Penokie, George; t10 at t10.org Cc: Voorhees, Bill Subject: RE: Typo in latest spec SPL3R04 for Persistent Connections - 1 message with two sources Hi George, I agree that one should not make assumptions about the default states and would agree that language be added to the PortLayer to state that the default state is P.C.E (Disabled). As you mention, if the default state of the PL is PCE disabled, then the additional messages are not needed, so I think that would be a cleaner and simpler solution in the spec. Another alternative is to have the EM send the P.C.E (disabled) confirmation to the PL upon entry to EM1, thus preserving a single source for the confirmation. You mentioned there are other cases of messages or confirmations originating |from two different state machines. I can not however find any examples of that in the standard. Can you point me to some that have two sources outside the new material? I'm pretty sure that Elliot was very careful not to allow that and it was a fundamental rule. Thanks Craig From: Penokie, George [mailto:George.Penokie at lsi.com] Sent: Thursday, September 19, 2013 9:53 AM To: Craig Stoops; t10 at t10.org Cc: Voorhees, Bill Subject: RE: Typo in latest spec SPL3R04 for Persistent Connections - 1 message with two sources Craig, Persistent Connection () is not a message it is a confirmation that is sent to the port layer. There are many confirmations that are same that come from different states and state machines that are the same. As for the Persistent Connection () confirmation here is the issue that adding it to the SL_CC2:Connected state from proposal 13-158. There are two cases in where the initial EXTEND_CONNECTION from the target could get lost or corrupted that would cause the handshake to not complete. a) If the target's EM1 receives a Persistent Connection (Transmit) the target will transmit the EXTEND_CONNECTION and then wait for an EXTEND_CONNECTION to be received. If the EXTEND_CONNECTION is never received, then EM1 never sends a Persistent Connection Established (Enable) to the port layer and there is no transition out of EM1. Assuming the port layer does not initialize to the persistent connection being enabled then it should have the persistent connection disabled. b) If the initiator's EM1 receives a Persistent Connection (Wait) the initiator will wait unit it gets the EXTEND_CONNECTION. When the EXTEND_CONNECTION is received the initiator will transmit an EXTEND_CONNECTION and send a Persistent Connection Established (Enable) to the port layer. At that point there is also a transition to EM2. If, for some reason, the target never receives the EXTEND_CONNECTION its EM1 will never send an Persistent Connection Established (Enable) to the port layer nor will there be a transition to its EM2. The result is the target will not send any EXTEND_CONNECTIONs. This will cause the initiator's EM2 to timeout resulting in a an Persistent Connection Established (Disable) to the port layer. So assuming the port layer defaults to persistent connections disabled there should be no hangs. However, one should never make assumptions about the creativity of those reading standards. Bye for now, George Penokie LSI Corporation 3033 41 St NW Rochester , MN 55901 507-328-9017 george.penokie at lsi.com From: Craig Stoops [mailto:Craig.Stoops at synopsys.com] Sent: Wednesday, September 18, 2013 8:26 PM To: Penokie, George; t10 at t10.org Cc: Voorhees, Bill Subject: Typo in latest spec SPL3R04 for Persistent Connections - 1 message with two sources Hi George, It was brought to my attention that in the SPL3R04 that the some new language was added to the SLCC however the message is now generated by both the SLCC and the EM. Previous proposals only have the message coming from the EM. The SLCC sends the Persistent Connection () message to the EM, and the EM does the rest. The PL should be assuming that unless it has received a message from the EM, that no PC has been established. So the need for the SLCC to send "disabled" is not needed, it's obvious that no PC has been enabled as far as the PL is concerned on a new connection. Most importantly though, there should only be 1 source of the message, and I believe the proposals were correct that it should come from the EM. The source should the solely the EM or solely the SLCC, not a mix. There is no other messages in the architecture that have two sources. Craig 6.16.4.5.1 State description a) an Extend Connection (Transmit) argument, then this state shall: A) send a Persistent Connection (Transmit) message to the SSP_EM link layer state machine (see 6.18.9.12); and B) send a Persistent Connection Established (Disabled) confirmation to the port layer.; b) an Extend Connection (Wait) argument, then this state shall: A) send a Persistent Connection (Wait) message to the SSP_EM link layer state machine (see 6.18.9.12); and B) send a Persistent Connection Established (Disabled) confirmation to the port layer; 6.18.9.12.2 SSP_EM1:Establish state This state establishes a persistent connection (see 6.18.1). If this state receives a Persistent Connection (Transmit) message, then this state: a) shall send a Transmit EXTEND_CONNECTION message to the SSP transmitter; and b) if this state receives an EXTEND_CONNECTION Received message, then this state shall send a Persistent Connection Established (Enabled) confirmation to the port layer. If this state receives a Persistent Connection (Wait) message and receives an EXTEND_CONNECTION Received message, then this state shall: a) send a Transmit EXTEND_CONNECTION message to the SSP transmitter; and b) send a Persistent Connection Established (Enabled) confirmation to the port layer. If this state receives a Persistent Connection (Off) message, then this state shall: a) ignore EXTEND_CONNECTION Received messages; and b) send a Persistent Connection Established (Disabled) confirmation to the port layer. From Craig.Stoops at synopsys.com Thu Sep 19 14:39:53 2013 From: Craig.Stoops at synopsys.com (Craig Stoops) Date: Thu, 19 Sep 2013 21:39:53 +0000 Subject: FW: Comment on T10/13-138r0 SPL-3 CREDIT ADVANCE for OPEN_ACCEPT Message-ID: Formatted message: HTML-formatted message Hi Tim, A side effect of your proposal is that if the recipient of the OAF does not support the credit advance, that the originator of the connection will have sacrificed 1 credit permanently for that connection since the OAF originator has no way of knowing whether the recipient will take advantage of the implied credit. One way around this is to borrow from Fibre Channel and have the recipient ignore the 1st RRDY received IF it supports the credit advance bit in the received OAF and that bit was sent. In keeping with that, the originator of the OAF would always send an RRDY for the advanced credit, which will be discarded if advance is supported or otherwise used normally if advance is not supported. This will keep the number of RRDY's consistent with the credits in the system regardless of use of credit advance or not. Otherwise, the rrdy's will always be 1 less, and the originator will have to hold the credit in reserve throughout the connection. A bit of a waste. Another, more complicated mechanism is to introduce the concept like login credits / AL bb credit where discovery of the endpoint tells us about the number of implied credits for new connections. I'm not in favor of that solution. Lastly, wish this could somehow be symentric, because clearly the one that would benefit the most if the originator of the OAF since we KNOW that side has a frame to transmit. Thoughts? Craig From bill.martin at ssi.samsung.com Thu Sep 19 22:30:45 2013 From: bill.martin at ssi.samsung.com (Bill Martin-SSI) Date: Fri, 20 Sep 2013 05:30:45 +0000 Subject: Comment on T10/13-138r0 SPL-3 CREDIT ADVANCE for OPEN_ACCEPT Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * Bill Martin-SSI * Craig Your first suggestion was discussed st the meeting. As to the second, about the credit from the other side, the originator of the OAF has to wait for an acknowledgement that the connection is open which may immediately be followed by an RRDY so there really isn't much extra delay in that direction. Bill Martin SSD I/O Standards Samsung Semiconductors, Inc. Cell (408) 499-1839 -------- Original message -------- From: Craig Stoops Date: 09/19/2013 3:28 PM (GMT-08:00) To: "Tim Symons (Tim.Symons at pmcs.com)" Cc: t10 at t10.org Subject: FW: Comment on T10/13-138r0 SPL-3 CREDIT ADVANCE for OPEN_ACCEPT Hi Tim, A side effect of your proposal is that if the recipient of the OAF does not support the credit advance, that the originator of the connection will have sacrificed 1 credit permanently for that connection since the OAF originator has no way of knowing whether the recipient will take advantage of the implied credit. One way around this is to borrow from Fibre Channel and have the recipient ignore the 1st RRDY received IF it supports the credit advance bit in the received OAF and that bit was sent. In keeping with that, the originator of the OAF would always send an RRDY for the advanced credit, which will be discarded if advance is supported or otherwise used normally if advance is not supported. This will keep the number of RRDY?s consistent with the credits in the system regardless of use of credit advance or not. Otherwise, the rrdy?s will always be 1 less, and the originator will have to hold the credit in reserve throughout the connection. A bit of a waste. Another, more complicated mechanism is to introduce the concept like login credits / AL bb credit where discovery of the endpoint tells us about the number of implied credits for new connections. I?m not in favor of that solution. Lastly, wish this could somehow be symentric, because clearly the one that would benefit the most if the originator of the OAF since we KNOW that side has a frame to transmit. Thoughts? Craig * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From IeWei.Njoo at pmcs.com Fri Sep 20 17:46:42 2013 From: IeWei.Njoo at pmcs.com (Ie Njoo) Date: Fri, 20 Sep 2013 17:46:42 -0700 Subject: pqi-r07 is available Message-ID: Formatted message: HTML-formatted message Hi, PQI-R07 which is the revision of PQI that contains all the Letter Ballot comment resolutions is available in T10: http://www.t10.org/cgi-bin/ac.pl?t=f&f=pqi-r07.pdf This is also the revision that has been approved during the Plenary Meeting #117 Sep 16-20 2013 to be forwarded to INCITS. Regards, Ie Wei Njoo PMC-Sierra From lohmeyer at t10.org Sat Sep 21 09:41:41 2013 From: lohmeyer at t10.org (John Lohmeyer) Date: Sat, 21 Sep 2013 10:41:41 -0600 Subject: T10 letter ballot on forwarding SPL-3 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * John Lohmeyer * Attention T10 voting members: A T10 letter ballot has been issued on forwarding SPL-3 revision 6 to INCITS for first public review. This ballot closes at 12 noon MDT on October 31, 2013. The T10.org letter ballot automation had a glitch when the ballot was issued and some notification emails were not sent out (including the one to me). I am still debugging what went wrong, but please do review SPL-3 revision 6 and vote using the following link: http://www.t10.org/members/13-247r0.htm Thanks, John -- John Lohmeyer Email: lohmeyer at t10.org LSI Corp. Voice: +1-719-533-7560 4420 ArrowsWest Dr. Cell: +1-719-338-1642 Colo Spgs, CO 80907 * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Ralph.Weber at wdc.com Sat Sep 21 09:45:03 2013 From: Ralph.Weber at wdc.com (Ralph Weber) Date: Sat, 21 Sep 2013 16:45:03 +0000 Subject: SPC-4 LB Resolution Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-3608-4.txt SPC-4 Letter Ballot resolution 9/30 3-5 pm CDT Ralph Weber invites you to an online meeting using WebEx. Meeting Number: 275 308 743 Meeting Password: This meeting does not require a password. ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://premconf.webex.com/premconf/j.php?J=275308743 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: This meeting does not require a password. 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll-free number (Premiere): 1-866-546-3377 (US) Call-in number (Premiere): 1-719-234-7872 (US) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6329833233&num=1866-546 -3377&num2=1719-234-7872 Attendee access code: 632 983 3233 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From Ralph.Weber at wdc.com Sat Sep 21 11:17:20 2013 From: Ralph.Weber at wdc.com (Ralph Weber) Date: Sat, 21 Sep 2013 18:17:20 +0000 Subject: SPC-4 LB Resolution Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-2932-3.txt SPC-4 Letter Ballot resolution Tues 10/8 3-5 pm CDT Ralph Weber invites you to an online meeting using WebEx. Meeting Number: 270 638 937 Meeting Password: This meeting does not require a password. ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://premconf.webex.com/premconf/j.php?J=270638937 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: This meeting does not require a password. 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll-free number (Premiere): 1-866-546-3377 (US) Call-in number (Premiere): 1-719-234-7872 (US) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6329833233&num=1866-546 -3377&num2=1719-234-7872 Attendee access code: 632 983 3233 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From Ralph.Weber at wdc.com Sat Sep 21 11:18:54 2013 From: Ralph.Weber at wdc.com (Ralph Weber) Date: Sat, 21 Sep 2013 18:18:54 +0000 Subject: SPC-4 LB Resolution Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-556-3.txt SPC-4 Letter Ballot resolution Wed 10/16 3-5 pm CDT Ralph Weber invites you to an online meeting using WebEx. Meeting Number: 278 619 613 Meeting Password: This meeting does not require a password. ------------------------------------------------------- To join this meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://premconf.webex.com/premconf/j.php?J=278619613 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: This meeting does not require a password. 4. Click "Join". 5. Follow the instructions that appear on your screen. ------------------------------------------------------- Teleconference information ------------------------------------------------------- Call-in toll-free number (Premiere): 1-866-546-3377 (US) Call-in number (Premiere): 1-719-234-7872 (US) Show global numbers: https://www.myrcplus.com/cnums.asp?bwebid=8369444&ppc=6329833233&num=1866-546 -3377&num2=1719-234-7872 Attendee access code: 632 983 3233 http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From lohmeyer at t10.org Sat Sep 21 23:02:06 2013 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 22 Sep 2013 00:02:06 -0600 Subject: Recent T10 documents uploaded since 2013/09/15 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SAM-5 ABORT TASK with overlapped commands (by: Rob Elliott) T10/12-189r5 Uploaded: 2013/09/18 230333 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-189r5.pdf SPC-5: Device Internal Status Dump (by: Frederick Knight) T10/13-029r1 Uploaded: 2013/09/15 243485 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-029r1.pdf T13 Liaison Report to T10 (by: Dan Colegrove) T10/13-039r4 Uploaded: 2013/09/19 65687 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-039r4.pdf SSC-5: Logical Block Protection Length error example (by: Kevin Butt) T10/13-049r2 Uploaded: 2013/09/19 61681 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-049r2.pdf SBC-4 SPC-5 Supported Block lengths and protection types VPD page (by: William Martin) T10/13-094r1 Uploaded: 2013/09/16 144270 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-094r1.pdf SBC-4 SPC-5 Supported Block lengths and protection types VPD page (by: William Martin) T10/13-094r2 Uploaded: 2013/09/16 142416 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-094r2.pdf SPL-3: Would Hunt (by: George Penokie) T10/13-208r1 Uploaded: 2013/09/18 92667 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-208r1.pdf SBC-3 Define read, verify, and write operations (by: Rob Elliott) T10/13-213r2 Uploaded: 2013/09/16 284518 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-213r2.pdf SBC-3 Define read, verify, and write operations (by: Rob Elliott) T10/13-213r3 Uploaded: 2013/09/16 284727 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-213r3.pdf Project Proposal: Serial Attached SCSI - 4 (by: Alvin Cox) T10/13-215r1 Uploaded: 2013/09/18 99304 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-215r1.pdf SPC-x Add new command timeout sense codes (by: Gerald Houlder) T10/13-218r1 Uploaded: 2013/09/16 26729 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-218r1.pdf SPL-3: Persistent Connection Establishment Fix (by: George Penokie) T10/13-222r1 Uploaded: 2013/09/18 70722 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-222r1.pdf Minutes of CAP Working Group - September 16-17, 2013 (by: Weber & Lohmeyer) T10/13-226r0 Uploaded: 2013/09/18 66364 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-226r0.htm Minutes of CAP Working Group - September 16-17, 2013 (by: Weber & Lohmeyer) T10/13-226r0 Uploaded: 2013/09/18 169848 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-226r0.pdf Minutes of SAS Protocol Working Group - September 18, 2013 (by: Weber & Lohmeyer) T10/13-227r0 Uploaded: 2013/09/21 39129 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-227r0.htm Minutes of SAS Protocol Working Group - September 18, 2013 (by: Weber & Lohmeyer) T10/13-227r0 Uploaded: 2013/09/21 111731 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-227r0.pdf SAM-5/SPC-4: Conglomerate / Hierarchical interaction clarification (by: Frederick Knight) T10/13-231r0 Uploaded: 2013/09/15 169441 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-231r0.pdf Minutes of SSC-5 Working Group - September 18, 2013 (by: Paul Suhler) T10/13-233r0 Uploaded: 2013/09/19 108726 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-233r0.pdf SSC-5 Working Group Report to Plenary, September 2013 (by: Paul Suhler) T10/13-234r0 Uploaded: 2013/09/19 25549 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-234r0.pdf SPC-5, Lack of clarity of LUN scope in WRITE BUFFER (by: John Geldman) T10/13-235r0 Uploaded: 2013/09/16 25300 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-235r0.pdf SPC-5, Lack of clarity of LUN scope in WRITE BUFFER (by: John Geldman) T10/13-235r1 Uploaded: 2013/09/17 11534 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-235r1.pdf SAS-4, 24Gb/s, Alternate Internal 8x connector Proposal (by: Greg McSorley) T10/13-236r0 Uploaded: 2013/09/17 870361 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-236r0.pdf Minutes of SAS PHY Working Group - September 17, 2013 (by: Alvin Cox) T10/13-237r0 Uploaded: 2013/09/19 45353 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-237r0.pdf SAS-3 PHY: ISI stress & TxRx connection data (by: Graeme Boyd) T10/13-238r0 Uploaded: 2013/09/17 425246 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-238r0.pdf SAS-3 letter ballot comment resolution, SAS3_EYEOPENING pulse response (by: Alvin Cox) T10/13-240r0 Uploaded: 2013/09/17 193201 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-240r0.pdf PQI Sub Letter Ballot Comments Incorporated in pqi-r06l (by: Ie-Wei Njoo) T10/13-241r0 Uploaded: 2013/09/18 25616 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-241r0.fdf PQI Sub Letter Ballot Comments Incorporated in pqi-r06l (by: Ie-Wei Njoo) T10/13-241r0 Uploaded: 2013/09/18 86203 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-241r0.pdf PQI Sub Letter Ballot Comments Incorporated in pqi-r06l (by: Ie-Wei Njoo) T10/13-241r0 Uploaded: 2013/09/18 125952 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-241r0.xls SAM-5: SOP for Table B.2 (by: Ralph Weber) T10/13-242r0 Uploaded: 2013/09/18 174235 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-242r0.pdf STA - T10 Liaison Report September 19, 2013 (by: Marty Czekalski) T10/13-243r0 Uploaded: 2013/09/18 312062 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-243r0.pdf IETF Liaison Report to T10 (by: David Black) T10/13-244r0 Uploaded: 2013/09/19 679687 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-244r0.pdf SNIA Liaison Report Sept 2013 (by: Frederick Knight) T10/13-245r0 Uploaded: 2013/09/19 89244 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-245r0.pdf JEDEC JC64.1 Liason Report 2013-09 (by: John Geldman) T10/13-246r0 Uploaded: 2013/09/19 110100 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-246r0.pdf Letter Ballot on forwarding SPL-3 to First Public Review (by: John Lohmeyer) T10/13-247r0 Uploaded: 2013/09/19 34279 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-247r0.pdf Agenda for T10 Meeting #117 (by: John Lohmeyer) T10/13-249r0 Uploaded: 2013/09/19 14956 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-249r0.pdf T10 Project Summary - September 2013 (by: John Lohmeyer) T10/13-250r0 Uploaded: 2013/09/21 29814 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-250r0.pdf Jeopardy Letter for November 2013 meeting (by: John Lohmeyer) T10/13-251r0 Uploaded: 2013/09/19 30858 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-251r0.pdf Working Drafts -------------- PCIe(r) architecture Queuing Interface (PQI) (Editor: Ie-Wei Njoo) Rev: 07 Uploaded: 2013/09/20 2213648 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=pqi-r07.pdf SAS Protocol Layer - 3 (SPL-3) (Editor: George Penokie) Rev: 05 Uploaded: 2013/09/19 9474894 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl3r05.pdf SAS Protocol Layer - 3 (SPL-3) (Editor: George Penokie) Rev: 06 Uploaded: 2013/09/19 9445708 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=spl3r06.pdf (Report generated on 2013/09/22 at 00:02:05) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From jgeldman at micron.com Sun Sep 22 22:49:14 2013 From: jgeldman at micron.com (John Geldman (jgeldman)) Date: Mon, 23 Sep 2013 05:49:14 +0000 Subject: ANSI INCITS TR38-2005 vs ACS-3 Message-ID: Formatted message: HTML-formatted message I don???t have a reason, but a further question. Why isn???t TR38-2005 available on t13.org in the technical reports area? Thanks, John From: owner-t13 at LISTS.WDC.COM [mailto:owner-t13 at LISTS.WDC.COM] On Behalf Of Ralph Weber Sent: Tuesday, August 06, 2013 5:48 AM To: T13 at T13.org Subject: [T13] ANSI INCITS TR38-2005 vs ACS-3 Can anybody justify the presence of the following normative reference in ACS-3? SMART Command Transport (SCT) -- ANSI INCITS TR38-2005 In ACS-3, the entirety of Clause 8 and Annex C are devoted to defining (dare I say "redefining") SCT. I cannot think of a valid reason for putting the 2005 TR in the Bibliography, let alone Clause 2. All the best, .Ralph From apoorva.vats at synopsys.com Sun Sep 22 23:46:19 2013 From: apoorva.vats at synopsys.com (Apoorva Vats) Date: Mon, 23 Sep 2013 06:46:19 +0000 Subject: SMP REQUEST/SMP RESPONSE timer query Message-ID: Formatted message: HTML-formatted message Hi , I sent a Query regarding SMP REQUEST/SMP RESPONSE timer on August 22 and Did not receive any update on this. Please update on this query. Regards, Apoorva From: Apoorva Vats Sent: Thursday, August 22, 2013 12:24 PM To: t10 at t10.org Subject: SMP REQUEST/SMP RESPONSE timer query Hi, As specified in "SAS Protocol Layer - 3 (SPL-3) " version specification (T10/BSR INCITS 492)( Revision 02 / 16 January 2013) Page no. 443 6.20 SMP link layer 6.20.1 SMP frame transmission and reception Inside an SMP connection, the SMP initiator phy transmits a single SMP_REQUEST frame within 100 ?s and the SMP target phy responds with a single SMP_RESPONSE frame (see 8.4) within 1 900 ?s. And at page no. 547 Table 187 - MT_TP time limits Time limit Value Description SMP Response time limit 1 900 ?s Maximum time from receiving an SMP_REQUEST frame to transmitting an SMP_RESPONSE frame Here specification specifies 2 timers. 1 for Request frame and other for Response frame. 1) 100 ?s timer runs at Initiator end and; 2) 1900 ?s timer runs at Target end. And at page no.548 8.4.5.3.3 MT_TP2:Respond state 8.4.5.3.3.1 State description This state waits for a Send SMP Response request, which includes the following argument: a) Response Bytes. After receiving a Send SMP Response request, this state shall construct an SMP_RESPONSE frame using the arguments from the Send SMP Response request and send a Transmit Frame request to the port layer within the SMP Response time limit specified in table 187 (see 8.4.5.3.1). This specifies that within SMP Response time limit SMP RESPONSE frame should be sent by the Target but no action is specified in the specification, if this does not happen within this time limit. Similarly, Specification does not mention anything if SMP initiator phy does not transmit SMP_REQUEST frame within 100 ?s. Firstly, I have few queries regarding 100 us timer :- 1) What happens if Initiator doesn't transmit SMP REQUEST frame even after 100 ?s get passed after the connection is established? 2) Why this timer is running in SMP Initiator instead of SMP Target ? I believe the SMP Target should wait for 100 us after SMP connection is established to receive a SMP Request Frame. Secondly, following queries are with respect to 1900 us time limit: 3) What happens if Target doesn't transmit SMP RESPONSE frame even after 1900 ?s get passed after receiving SMP REQUEST frame. 4) Why this timer is running in SMP Target instead of SMP Initiator ? I believe the SMP Initiator should wait for 1900 us after SMP request is sent to receive a SMP Response Frame. Regards, Apoorva From curtis.stevens at wdc.com Mon Sep 23 08:47:26 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Mon, 23 Sep 2013 15:47:26 +0000 Subject: SOP Teleconference Message-ID: Formatted message: HTML-formatted message We have a teleconference set for today. I am still working on the changes |from plenary week and am not quite ready. I can still hold the conference, but think the time could be best used without the conference. ------------------------------------------------- Curtis E. Stevens Director, Standards & Features Technology 3355 Michelson Dr. #100 Office: 1-1041 Irvine, Ca. 92612 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: Curtis.Stevens at WDC.com Remember, you may only be blamed for something if you are actually doing something. From bill.martin at ssi.samsung.com Mon Sep 23 09:24:41 2013 From: bill.martin at ssi.samsung.com (Bill Martin-SSI) Date: Mon, 23 Sep 2013 16:24:41 +0000 Subject: SOP Teleconference Message-ID: Formatted message: HTML-formatted message I am fine with canceling. If you have nothing constructive to discuss today, then it would be better to wait until October 7. Bill Martin SSD I/O Standards Samsung Semiconductor, Inc. Cell (916) 765-6875 From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Curtis Stevens Sent: Monday, September 23, 2013 8:47 AM To: T10 at t10.org Subject: SOP Teleconference We have a teleconference set for today. I am still working on the changes |from plenary week and am not quite ready. I can still hold the conference, but think the time could be best used without the conference. ------------------------------------------------- Curtis E. Stevens Director, Standards & Features Technology 3355 Michelson Dr. #100 Office: 1-1041 Irvine, Ca. 92612 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: Curtis.Stevens at WDC.com Remember, you may only be blamed for something if you are actually doing something. From curtis.stevens at wdc.com Mon Sep 23 10:35:30 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Mon, 23 Sep 2013 17:35:30 +0000 Subject: Canceled: SOPQI WG Message-ID: Formatted message: HTML-formatted message Attachment #1: nameless-3300-3.txt 17-Sep Please note that the conference bridge has changed. Date: 23-Sep-2013, Time: 12:30-2:30 Pacific Time Meeting to focus on SOP From curtis.stevens at wdc.com Mon Sep 23 10:37:04 2013 From: curtis.stevens at wdc.com (Curtis Stevens) Date: Mon, 23 Sep 2013 17:37:04 +0000 Subject: SOP Teleconference Message-ID: Formatted message: HTML-formatted message The ayes have it for cancelling the meeting. I have issued a cancellation notice. The next telecon is 7-Oct. ------------------------------------------------- Curtis E. Stevens Director, Standards & Features Technology 3355 Michelson Dr. #100 Office: 1-1041 Irvine, Ca. 92612 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: Curtis.Stevens at WDC.com Remember, you may only be blamed for something if you are actually doing something. From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Curtis Stevens Sent: Monday, September 23, 2013 8:47 AM To: T10 at t10.org Subject: SOP Teleconference We have a teleconference set for today. I am still working on the changes |from plenary week and am not quite ready. I can still hold the conference, but think the time could be best used without the conference. ------------------------------------------------- Curtis E. Stevens Director, Standards & Features Technology 3355 Michelson Dr. #100 Office: 1-1041 Irvine, Ca. 92612 Phone: 949-672-7933 Cell: 949-307-5050 E-Mail: Curtis.Stevens at WDC.com Remember, you may only be blamed for something if you are actually doing something. From lohmeyer at t10.org Mon Sep 23 13:12:50 2013 From: lohmeyer at t10.org (John Lohmeyer) Date: Mon, 23 Sep 2013 14:12:50 -0600 Subject: T10 Reflector clean up Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * John Lohmeyer * # # # # # # # # # # It is time again to clean up the T10 Reflector. The following addresses have bounced consistently since the last clean up and are being removed: Alex.Mohandas at emc.com pritchard_jason at emc.com B18529 at freescale.com Jack.Hollins at lsi.com dave_davis at uk.xyratex.com Larry.Lomelino at Emulex.Com Anthony_K_Wright at Dell.com ykagan at unigen.com ed.cady at volex.com markben at microsoft.com ErnandoAriel.M.Bangayan at bitmicro.com Noeme.P.Mateo at bitmicro.com satoshi.kitani at jp.sony.com Tim.Mcleod at netapp.com agy at netapp.com bharaths at netapp.com mark.nossokoff at netapp.com keith.son at netapp.com satoshi.kitani at jp.sony.com bschuh at us.ibm.com daniel.colegrove at hgst.com These people may re-subscribe (hopefully, with a better address) by using the following URL: http://www.t10.org/t10r.htm -- John Lohmeyer Email: lohmeyer at t10.org LSI Corp. Voice: +1-719-533-7560 4420 ArrowsWest Dr. Cell: +1-719-338-1642 Colo Spgs, CO 80907 * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From dave.b.anderson at seagate.com Tue Sep 24 07:51:59 2013 From: dave.b.anderson at seagate.com (Dave B Anderson) Date: Tue, 24 Sep 2013 09:51:59 -0500 Subject: SMR drive session at Linux Plumbers Message-ID: Formatted message: HTML-formatted message FYI I used the slides at the Library of Congress yesterday, and they will post the slides as well. Dave On Sep 24, 2013 9:23 AM, "Gerry Houlder" wrote: > A PDF version of the slides is available from T10.org site as document > 13-229r0.pdf. Anyone can download proposals from this site, but first time > visitors will be asked to register first. i have attached that document > here for convenience. > > > On Mon, Sep 23, 2013 at 8:31 PM, James Borden wrote: > >> Yes, we were extremely happy at the attendance and great questions. I am >> working on a summary of the meeting for the group; this will help us be >> well prepared for CloudOpen next month. >> >> James >> >> >> James Borden >> >> Director of Enterprise Storage Marketing >> Western Digital Corporation >> >> 2331 130th Ave NE, Suite 110 >> Bellevue WA 98005 >> >> 425-213-3830 (Mobile) >> 425-755-1034 (Office) >> 425-636-1411 (Fax) >> >> -----Original Message----- >> From: Ric Wheeler [mailto:rwheeler at redhat.com] >> Sent: Monday, September 23, 2013 6:08 PM >> To: Jorge.Campello at hgst.com >> Cc: Dave B Anderson; Curtis Stevens; Dan Colegrove; Gerry Houlder; >> Christoph Hellwig; James Borden; Jim Hatfield; Jim Malina; Mike >> Fitzpatrick; Mike H Miller; Patrick Hery; T10 Reflector; William Boyle; >> Zvonimir Bandic >> Subject: SMR drive session at Linux Plumbers >> >> >> My impression is that we had a very solid session at plumbers, I think >> that we managed to reach out to a fair number of developers (including >> Christoph in this email :)). Thanks to everyone for attending! >> >> Can we get a copy of the slides presented to share broadly? >> >> Regards, >> >> Ric >> >> > From George.Penokie at lsi.com Tue Sep 24 13:01:11 2013 From: George.Penokie at lsi.com (Penokie, George) Date: Tue, 24 Sep 2013 14:01:11 -0600 Subject: T10 Working Draft Assignment: sbc3r35j Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * "Penokie, George" * A clean version of SBC-3 (sbcr35j) with all markups removed is now available on the T10 website at the following URL: http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r35j.pdf A version of SBC-3 (sccr35i) with all the markups from the letter ballot is also available on the T10 website. Bye for now, George Penokie LSI Corporation 3033 41 St NW Rochester , MN 55901 507-328-9017 george.penokie at lsi.com * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From rajneesh.kumar at synopsys.com Wed Sep 25 05:19:49 2013 From: rajneesh.kumar at synopsys.com (Rajneesh Kumar) Date: Wed, 25 Sep 2013 12:19:49 +0000 Subject: Issue in description for Error code field (ERROR Response TTIU) Message-ID: Formatted message: HTML-formatted message Hi, In below mentioned portion of "Table 66 - ERROR CODE field" (referred spl-3 revision 04, 24-July 2013), I have a finding: ? If we consider description (a) of 1Ah Error code then there are valid combinations (refer table 63) where none of coefficient request are set to 11b. Hence for any valid combination, false error will be reported. I think description (b) is sufficient for this error code. Code Name Description 1Ah RESERVED COEFFICIENT REQUEST COMBINATION One of the following occurs: a) none of the coefficient requests are set 11b (i.e., reserved) (see table 62); b) the combination of the coefficient 3 request, coefficient 2 request, and coefficient 1 request is reserved (see table 63). Please share your views on the same. Regards, Rajneesh From lohmeyer at t10.org Wed Sep 25 10:02:06 2013 From: lohmeyer at t10.org (John Lohmeyer) Date: Wed, 25 Sep 2013 11:02:06 -0600 Subject: draft T10 Plenary minutes posted Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * John Lohmeyer * The draft minutes of the September 19, 2013 T10 Plenary meeting #117 are available at: http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-228r0.htm -- John Lohmeyer Email: lohmeyer at t10.org LSI Corp. Voice: +1-719-533-7560 4420 ArrowsWest Dr. Cell: +1-719-338-1642 Colo Spgs, CO 80907 * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Frederick.Knight at netapp.com Wed Sep 25 12:14:23 2013 From: Frederick.Knight at netapp.com (Knight, Frederick) Date: Wed, 25 Sep 2013 19:14:23 +0000 Subject: SBC-3r35i/j issue Message-ID: Formatted message: HTML-formatted message OK folks, it looks like we made a mistake in 13-213r3. We had an a) ... or b) list where adding a word caused a significant functional change. There are 2 possible corrections (remove the word we added, or add more words). My suggestion is that we add the additional words so that the both the a) conditions and the b) conditions apply to the then portion of the statement: 4.7.3.7 Thin provisioned logical unit resource exhaustion considerations If: a) a write operation is requested ... ; or b) an unmap operation that ... is requested ... then the device server shall terminate the command requesting the unmap operation with CHECK ... The problem is the change from the bare "operation" to a specific "unmap operation". The same addition of the word "unmap" occurs in the second a)/b) list as well, and the addition of that word in both places is the source of this new problem. The addition of that word now restricts the "then" clause to only apply to the b) case of the "if" and the a) case of the "if" now has no text in the "then" clause. The "then" clause is supposed to apply to both cases - a) ; or b). Either we need to remove "unmap" from that sentence. Or we need to change it to include both the unmap operation and the write operation - as in something like: If: a) a write operation is requested ... ; or b) an unmap operation that ... is requested ... then the device server shall terminate the command requesting the write operation or the unmap operation with CHECK ... Fred Knight From Elliott at hp.com Wed Sep 25 13:13:25 2013 From: Elliott at hp.com (Elliott, Robert (Server Storage)) Date: Wed, 25 Sep 2013 20:13:25 +0000 Subject: SBC-3r35i/j issue Message-ID: Formatted message: HTML-formatted message Based on teleconference discussion, 13-213r1 to r2 was supposed to remove "unmap" from both paragraphs, but that was missed and not noticed for r3. --- Rob Elliott HP Server Storage From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Knight, Frederick Sent: Wednesday, 25 September, 2013 2:14 PM To: T10 Reflector Subject: SBC-3r35i/j issue OK folks, it looks like we made a mistake in 13-213r3. We had an a) ... or b) list where adding a word caused a significant functional change. There are 2 possible corrections (remove the word we added, or add more words). My suggestion is that we add the additional words so that the both the a) conditions and the b) conditions apply to the then portion of the statement: 4.7.3.7 Thin provisioned logical unit resource exhaustion considerations If: a) a write operation is requested ... ; or b) an unmap operation that ... is requested ... then the device server shall terminate the command requesting the unmap operation with CHECK ... The problem is the change from the bare "operation" to a specific "unmap operation". The same addition of the word "unmap" occurs in the second a)/b) list as well, and the addition of that word in both places is the source of this new problem. The addition of that word now restricts the "then" clause to only apply to the b) case of the "if" and the a) case of the "if" now has no text in the "then" clause. The "then" clause is supposed to apply to both cases - a) ; or b). Either we need to remove "unmap" from that sentence. Or we need to change it to include both the unmap operation and the write operation - as in something like: If: a) a write operation is requested ... ; or b) an unmap operation that ... is requested ... then the device server shall terminate the command requesting the write operation or the unmap operation with CHECK ... Fred Knight From Ralph.Weber at wdc.com Fri Sep 27 13:53:59 2013 From: Ralph.Weber at wdc.com (Ralph Weber) Date: Fri, 27 Sep 2013 20:53:59 +0000 Subject: 4.15 specs for read operation are unacceptable in SBC-3 r35j Message-ID: Formatted message: HTML-formatted message Based on a preliminary review, Western Digital engineers have concerns about the two paragraphs in 4.15 of SBC-3 r35j that begin as follows: * For each LBA accessed by a read operation that is not a verify operation: * For each LBA accessed by read operation that is a verify operation: The initial concern was that some interpretations of the 'read operation that is a verify operation' case prohibit the use of read-ahead for verify operations. At a minimum, the cited paragraphs need to be revised as follows to maintain consistency throughout 4.15 (note, the write operation definition is included to demonstrate the need for consistency). For each LBA accessed by a write operation: 1) if a cache contains more recent logical block data for that LBA than the medium, then the device server shall: A) perform a write cache operation to that LBA to update the logical block data in the cache; B) invalidate that LBA in the cache and perform a write medium operation to that LBA; or C) perform a write cache operation to that LBA to update the logical block data in the cache and perform a write medium operation to that LBA. For each LBA accessed by a read operation that is not a verify operation: 1) if a cache contains more recent logical block data for that LBA than the medium, then the device server shall perform: A) a read cache operation from that LBA; or B) 2) the device server shall perform a read medium operation from that LBA. For each LBA accessed by read operation that is a verify operation: 1) if a cache contains more recent logical block data for the LBA than the medium, then the device server: A) shall perform a write medium operation to that LBA; B) 2) the device server may invalidate that LBA in the cache; and C) 3) the device server shall perform a verify medium operation from that LBA. Unless the second level of list is applied to all three paragraphs, the use of 'that LBA' is ambiguous vis a vis the if clause that establishes the operative conditions. Western Digital also is obliged to note that none of the three cited paragraphs cover the case where the cache fails to contain more recent logical block data for 'that LBA' despite the fact that the presence of a list based on this condition implies that such coverage ought to be present (i.e., the if clause could equally well be folded into the list introduction statement). To push the envelope a bit farther, some Western Digital reviewers suggested that the specific case of a 'read operation that is a verify operation' could be more fully stated as follows. For each LBA accessed by a read operation that is a verify operation, the device server shall perform a read cache operation only if: a) the logical block data in the cache for that LBA is the result of a read medium operation; and b) no subsequent write operation has been processed for that LBA. Warning: This comment is the result of a very preliminary review by Western Digital engineers. The Western Digital review of SBC-3 r35j is ongoing, and more issues seem likely to be unearthed. Due to the gravity of this issue Western Digital concluded that prompt disclosure would best serve the interests of T10 and the industry. All the best, .Ralph From Ralph.Weber at wdc.com Fri Sep 27 14:16:30 2013 From: Ralph.Weber at wdc.com (Ralph Weber) Date: Fri, 27 Sep 2013 21:16:30 +0000 Subject: SBC-3 r35j 4.15 text 'xxx medium operation that is not part of an xxx operation' leaves too much to the imagination Message-ID: Formatted message: HTML-formatted message While some of those present thought the intent was somehow related to specifying the proper operation of cache coherency implementations, Western Digital reviewers found the following two list introductions incomprehensibly vague in SBC-3 r35j. * For each LBA accessed by a write medium operation that is not part of a write operation: * For each LBA accessed by a read medium operation that is not part of a read operation: Is this intended to reach into the design of background operations? Proposing a solution based on the current, quicksand text seems like a dubious endeavor, at best. If the intent is to specify who a device server maintains cache coherency, the majority of Western Digital reviewers question the need for such untestable requirements in a T10 standard. If some other concern underlies the existing text, then perhaps the addition of an e.g. immediately prior to the colon will set the proper tone. One fear is clear. If nothing is done, over jealous test engineers are likely to extend their vision of the cache to include the sector write buffer that is part of the hardware that actually records data on the medium. Warning: This comment is the result of a very preliminary review by Western Digital engineers. The Western Digital review of SBC-3 r35j is ongoing, and more issues seem likely to be unearthed. Due to the gravity of this issue Western Digital concluded that prompt disclosure would best serve the interests of T10 and the industry. All the best, .Ralph From lohmeyer at t10.org Sat Sep 28 01:00:00 2013 From: lohmeyer at t10.org (T10 List Manager) Date: Sat, 28 Sep 2013 02:00:00 -0600 Subject: T10 Reflector Monthly Reminder Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 List Manager * This is an automatic monthly posting to the T10 Reflector. If you receive this message, it means that you are subscribed to the T10 Reflector email list. The T10 Reflector is provided by the SCSI Trade Association and maintained by LSI Corp. This reflector exists to discuss INCITS T10 Technical Committee issues and to disseminate T10-related information (minutes, meeting notices, etc.). --------------------------------------------------------------------------- You do not need to be an INCITS T10 Technical Committee member to use this reflector, however you must agree to: * read the INCITS Patent Policy and the INCITS Antitrust Guidelines * acknowledge that the activities of the T10 Technical Committee are governed by the INCITS policies and procedures as specified in the reference documents RD-1 and RD-2 * acknowledge that draft documents may change at any time, without notice. The INCITS Patent Policy, the INCITS Antitrust Guidelines, the RD-1, and the RD-2 are all available on the www.incits.org web site. If you do not agree to the above conditions, then you must unsubscribe to this reflector. --------------------------------------------------------------------------- T10 Reflector is not intended to carry commercial traffic. People who post advertisements, job offers, etc. will be removed from the reflector. Please visit http://www.t10.org/t10r.htm for instructions on subscribing, unsubscribing, or searching the T10 Reflector archives. * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From lohmeyer at t10.org Sat Sep 28 23:01:30 2013 From: lohmeyer at t10.org (T10 Document Administrator) Date: Sun, 29 Sep 2013 00:01:30 -0600 Subject: Recent T10 documents uploaded since 2013/09/22 Message-ID: * From the T10 Reflector (t10 at t10.org), posted by: * T10 Document Administrator * Proposals --------- SBC-3 Letter Ballot Comments Resolutions (by: George Penokie) T10/13-089r8 Uploaded: 2013/09/23 7792265 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-089r8.fdf SBC-3 Letter Ballot Comments Resolutions (by: George Penokie) T10/13-089r8 Uploaded: 2013/09/23 7749976 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-089r8.pdf Minutes of T10 Plenary Meeting #117 - September 19, 2013 (by: Weber & Lohmeyer) T10/13-228r0 Uploaded: 2013/09/25 136258 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-228r0.htm Minutes of T10 Plenary Meeting #117 - September 19, 2013 (by: Weber & Lohmeyer) T10/13-228r0 Uploaded: 2013/09/25 293795 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-228r0.pdf Minutes of SOP-PQI Working Group - 18-19 September 2013 (by: Rob Elliott) T10/13-239r0 Uploaded: 2013/09/24 189540 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-239r0.pdf T10 Project Summary - September 2013 (by: John Lohmeyer) T10/13-250r0 Uploaded: 2013/09/23 29876 bytes http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-250r0.pdf Working Drafts -------------- SCSI Block Commands - 3 (SBC-3) (Editor: George Penokie) Rev: 35i Uploaded: 2013/09/23 3150767 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r35i.pdf SCSI Block Commands - 3 (SBC-3) (Editor: George Penokie) Rev: 35j Uploaded: 2013/09/24 2839671 bytes http://www.t10.org/cgi-bin/ac.pl?t=f&f=sbc3r35j.pdf (Report generated on 2013/09/29 at 00:01:29) * * For T10 Reflector information, send a message with * 'info t10' (no quotes) in the message body to majordomo at t10.org From Elliott at hp.com Mon Sep 30 08:04:07 2013 From: Elliott at hp.com (Elliott, Robert (Server Storage)) Date: Mon, 30 Sep 2013 15:04:07 +0000 Subject: 4.15 specs for read operation are unacceptable in SBC-3 r35j Message-ID: Formatted message: HTML-formatted message From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber Sent: Friday, 27 September, 2013 3:54 PM To: t10 at t10.org Subject: 4.15 specs for read operation are unacceptable in SBC-3 r35j Based on a preliminary review, Western Digital engineers have concerns about the two paragraphs in 4.15 of SBC-3 r35j that begin as follows: * For each LBA accessed by a read operation that is not a verify operation: * For each LBA accessed by read operation that is a verify operation: The initial concern was that some interpretations of the 'read operation that is a verify operation' case prohibit the use of read-ahead for verify operations. At a minimum, the cited paragraphs need to be revised as follows to maintain consistency throughout 4.15 (note, the write operation definition is included to demonstrate the need for consistency). For each LBA accessed by a write operation: 1) if a cache contains more recent logical block data for that LBA than the medium, then the device server shall: A) perform a write cache operation to that LBA to update the logical block data in the cache; B) invalidate that LBA in the cache and perform a write medium operation to that LBA; or C) perform a write cache operation to that LBA to update the logical block data in the cache and perform a write medium operation to that LBA. For each LBA accessed by a read operation that is not a verify operation: 1) if a cache contains more recent logical block data for that LBA than the medium, then the device server shall perform: A) a read cache operation from that LBA; or B) 2) the device server shall perform a read medium operation from that LBA. RE: That wording for 1) B) would mean to read from medium even though there is more recent data in cache, which is not correct. If there is more recent data in cache, it must be used. For each LBA accessed by read operation that is a verify operation: 1) if a cache contains more recent logical block data for the LBA than the medium, then the device server: A) shall perform a write medium operation to that LBA; B) 2) the device server may invalidate that LBA in the cache; and C) 3) the device server shall perform a verify medium operation from that LBA. Unless the second level of list is applied to all three paragraphs, the use of 'that LBA' is ambiguous vis a vis the if clause that establishes the operative conditions. RE: For 1)B), Step 2) is not prefaced by "if ... more recent" because step 1) made the cache and medium identical. For step 1)C), the verify medium operation is always eventually performed; it's not just if there was a cache hit. The order is also very important here: 1) write to medium, 2) invalidate if desired, 3) verify. Running the verify before the data from cache has made it to the medium would not be correct. "that LBA" refers to "For each LBA" introducing the list. Western Digital also is obliged to note that none of the three cited paragraphs cover the case where the cache fails to contain more recent logical block data for 'that LBA' despite the fact that the presence of a list based on this condition implies that such coverage ought to be present (i.e., the if clause could equally well be folded into the list introduction statement). RE: That is not a problem unless the "if a cache contains more recent" preface applies to more list items than it should. To push the envelope a bit farther, some Western Digital reviewers suggested that the specific case of a 'read operation that is a verify operation' could be more fully stated as follows. For each LBA accessed by a read operation that is a verify operation, the device server shall perform a read cache operation only if: a) the logical block data in the cache for that LBA is the result of a read medium operation; and b) no subsequent write operation has been processed for that LBA. RE: It doesn't matter how the cache got the data. If there is more recent data in the cache, all verify operations need to force that data to media before performing the verify medium operation. Warning: This comment is the result of a very preliminary review by Western Digital engineers. The Western Digital review of SBC-3 r35j is ongoing, and more issues seem likely to be unearthed. Due to the gravity of this issue Western Digital concluded that prompt disclosure would best serve the interests of T10 and the industry. All the best, .Ralph From Ralph.Weber at wdc.com Mon Sep 30 08:33:42 2013 From: Ralph.Weber at wdc.com (Ralph Weber) Date: Mon, 30 Sep 2013 15:33:42 +0000 Subject: VERIFY & how the data got into the cache Message-ID: Formatted message: HTML-formatted message Unless I misheard them, WD engineers beg to differ with the following comments in the "4.15 specs for read operation" thread: <> For each LBA accessed by a read operation that is a verify operation, the device server shall perform a read cache operation only if: a) the logical block data in the cache for that LBA is the result of a read medium operation; and b) no subsequent write operation has been processed for that LBA. RE: It doesn?t matter how the cache got the data. If there is more recent data in the cache, all verify operations need to force that data to media before performing the verify medium operation. <> How the data got into the cache very much matters (or so my experts tell me). For this reason, WD engineering sees the current 4.15 requirements as being fixated on the wrong thing. VERIFY commands are required to use data that is read from the medium. If the cache contains data that is newer then: 1. that data must be written to the medium, 2. the cache must be invalidated, and 3. the data must be read from the medium (and stored in cache if so desired). Any specification that says otherwise is misleading the reader. It is not acceptable to write the newer cache data to the medium and then use the cache contents without first reading the medium, unless the goal of the letter ballot changes is to negate the first sentence in the SBC-2 definition of VERIFY ... to whit: "The VERIFY (10) command (see table 53) requests that the device server verify the specified logical block(s) on the medium." Furthermore, the "newer data in cache" issue should be covered by b) in the WD proposed wording. All the best, .Ralph From Elliott at hp.com Mon Sep 30 08:40:34 2013 From: Elliott at hp.com (Elliott, Robert (Server Storage)) Date: Mon, 30 Sep 2013 15:40:34 +0000 Subject: SBC-3 r35j 4.15 text 'xxx medium operation that is not part of an xxx operation' leaves too much to the imagination Message-ID: Formatted message: HTML-formatted message From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber Sent: Friday, 27 September, 2013 4:17 PM To: t10 at t10.org Subject: SBC-3 r35j 4.15 text 'xxx medium operation that is not part of an xxx operation' leaves too much to the imagination While some of those present thought the intent was somehow related to specifying the proper operation of cache coherency implementations, Western Digital reviewers found the following two list introductions incomprehensibly vague in SBC-3 r35j. * For each LBA accessed by a write medium operation that is not part of a write operation: * For each LBA accessed by a read medium operation that is not part of a read operation: Is this intended to reach into the design of background operations? Proposing a solution based on the current, quicksand text seems like a dubious endeavor, at best. If the intent is to specify who a device server maintains cache coherency, the majority of Western Digital reviewers question the need for such untestable requirements in a T10 standard. If some other concern underlies the existing text, then perhaps the addition of an e.g. immediately prior to the colon will set the proper tone. The intent is to be clear that every read medium operation must get data from the cache if more recent data is there, and every write medium operation must keep the cache up to date. It's a catch-all for commands like WRITE AND VERIFY and other model material that refers directly to medium operations but doesn't mention the cache impacts: Page 195 The WRITE AND VERIFY (10) command (see table 111) requests that the device server: 1) transfer the specified the logical block data for the command from the Data-Out Buffer; 2) perform write medium operations to the specified LBAs; 3) perform verify operations from the specified LBAs; and 4) if specified, perform a compare operation on: A) the logical block data transferred from the Data-Out Buffer; and B) the logical block data from the verify operations.... Maybe WRITE AND VERIFY should just be described as performing a write operation, because the verify operation includes the write medium operation if needed. One fear is clear. If nothing is done, over jealous test engineers are likely to extend their vision of the cache to include the sector write buffer that is part of the hardware that actually records data on the medium. Warning: This comment is the result of a very preliminary review by Western Digital engineers. The Western Digital review of SBC-3 r35j is ongoing, and more issues seem likely to be unearthed. Due to the gravity of this issue Western Digital concluded that prompt disclosure would best serve the interests of T10 and the industry. All the best, .Ralph From Ralph.Weber at wdc.com Mon Sep 30 08:47:03 2013 From: Ralph.Weber at wdc.com (Ralph Weber) Date: Mon, 30 Sep 2013 15:47:03 +0000 Subject: New SPC-4 Letter Ballot documents Message-ID: Formatted message: HTML-formatted message In honor of this afternoon's conference call, new SPC-4 letter ballot documents are being delivered to the T10 website. New resolution PDFs are available now: http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-311r8.pdf [primary document] http://www.t10.org/cgi-bin/ac.pl?t=d&f=13-070r2.pdf [supplementary document] The agenda for today's call appears on page 4 of 12-311r8.pdf. Instructions for using the various PDF files can be found on pages 1 and 2 of 12-311r8.pdf. For those who prefer to pull an FDF into SPC-4 r36, that file is already uploaded too. http://www.t10.org/cgi-bin/ac.pl?t=d&f=12-311r8.fdf Work is in progress to upload the SPC-4 companion for the above-named files, which will be SPC-4 r36j. When the upload succeeds, the PDF will be accessible as: http://www.t10.org/cgi-bin/ac.pl?t=f&f=spc4r36j.pdf SPC-4 r36j should be available by 1 pm CDT. All the best, .Ralph From Elliott at hp.com Mon Sep 30 08:49:26 2013 From: Elliott at hp.com (Elliott, Robert (Server Storage)) Date: Mon, 30 Sep 2013 15:49:26 +0000 Subject: 4.15 specs for read operation are unacceptable in SBC-3 r35j Message-ID: Formatted message: HTML-formatted message Prompted by Ralph's comment about the consistency with write operations paragraph, I think that paragraph: For each LBA accessed by a write operation: 1) if a cache contains more recent logical block data for that LBA than the medium, then the device server shall: A) perform a write cache operation for that LBA to update the logical block data in the cache; B) invalidate that LBA in the cache and perform a write medium operation for that LBA; or C) perform a write cache operation for that LBA to update the logical block data in the cache and perform a write medium operation for that LBA. is missing the following: or 2) perform a write medium operation for that LBA. As written, it only discusses the cache hit case; the cache miss case is missing. From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Elliott, Robert (Server Storage) Sent: Monday, 30 September, 2013 10:04 AM To: Ralph Weber; t10 at t10.org Subject: RE: 4.15 specs for read operation are unacceptable in SBC-3 r35j From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber Sent: Friday, 27 September, 2013 3:54 PM To: t10 at t10.org Subject: 4.15 specs for read operation are unacceptable in SBC-3 r35j Based on a preliminary review, Western Digital engineers have concerns about the two paragraphs in 4.15 of SBC-3 r35j that begin as follows: * For each LBA accessed by a read operation that is not a verify operation: * For each LBA accessed by read operation that is a verify operation: The initial concern was that some interpretations of the 'read operation that is a verify operation' case prohibit the use of read-ahead for verify operations. At a minimum, the cited paragraphs need to be revised as follows to maintain consistency throughout 4.15 (note, the write operation definition is included to demonstrate the need for consistency). For each LBA accessed by a write operation: 1) if a cache contains more recent logical block data for that LBA than the medium, then the device server shall: A) perform a write cache operation to that LBA to update the logical block data in the cache; B) invalidate that LBA in the cache and perform a write medium operation to that LBA; or C) perform a write cache operation to that LBA to update the logical block data in the cache and perform a write medium operation to that LBA. For each LBA accessed by a read operation that is not a verify operation: 1) if a cache contains more recent logical block data for that LBA than the medium, then the device server shall perform: A) a read cache operation from that LBA; or B) 2) the device server shall perform a read medium operation from that LBA. RE: That wording for 1) B) would mean to read from medium even though there is more recent data in cache, which is not correct. If there is more recent data in cache, it must be used. For each LBA accessed by read operation that is a verify operation: 1) if a cache contains more recent logical block data for the LBA than the medium, then the device server: A) shall perform a write medium operation to that LBA; B) 2) the device server may invalidate that LBA in the cache; and C) 3) the device server shall perform a verify medium operation from that LBA. Unless the second level of list is applied to all three paragraphs, the use of 'that LBA' is ambiguous vis a vis the if clause that establishes the operative conditions. RE: For 1)B), Step 2) is not prefaced by "if ... more recent" because step 1) made the cache and medium identical. For step 1)C), the verify medium operation is always eventually performed; it's not just if there was a cache hit. The order is also very important here: 1) write to medium, 2) invalidate if desired, 3) verify. Running the verify before the data from cache has made it to the medium would not be correct. "that LBA" refers to "For each LBA" introducing the list. Western Digital also is obliged to note that none of the three cited paragraphs cover the case where the cache fails to contain more recent logical block data for 'that LBA' despite the fact that the presence of a list based on this condition implies that such coverage ought to be present (i.e., the if clause could equally well be folded into the list introduction statement). RE: That is not a problem unless the "if a cache contains more recent" preface applies to more list items than it should. To push the envelope a bit farther, some Western Digital reviewers suggested that the specific case of a 'read operation that is a verify operation' could be more fully stated as follows. For each LBA accessed by a read operation that is a verify operation, the device server shall perform a read cache operation only if: a) the logical block data in the cache for that LBA is the result of a read medium operation; and b) no subsequent write operation has been processed for that LBA. RE: It doesn't matter how the cache got the data. If there is more recent data in the cache, all verify operations need to force that data to media before performing the verify medium operation. Warning: This comment is the result of a very preliminary review by Western Digital engineers. The Western Digital review of SBC-3 r35j is ongoing, and more issues seem likely to be unearthed. Due to the gravity of this issue Western Digital concluded that prompt disclosure would best serve the interests of T10 and the industry. All the best, .Ralph From Elliott at hp.com Mon Sep 30 08:57:04 2013 From: Elliott at hp.com (Elliott, Robert (Server Storage)) Date: Mon, 30 Sep 2013 15:57:04 +0000 Subject: VERIFY & how the data got into the cache Message-ID: Formatted message: HTML-formatted message The blue text is your proposed text, not the sbc3r35j text. sbc3r35j does not specify "read cache operation" for verify; it specifies "write medium operation." sbc3r35j: For each LBA accessed by a read operation that is not a verify operation: 1) if a cache contains more recent logical block data for that LBA than the medium, then the device server shall perform a read cache operation from that LBA; or 2) the device server shall perform a read medium operation from that LBA. For each LBA accessed by read operation that is a verify operation: 1) if a cache contains more recent logical block data for the LBA than the medium, then the device server shall perform a write medium operation to that LBA; 2) the device server may invalidate that LBA in the cache; and 3) the device server shall perform a verify medium operation from that LBA. From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber Sent: Monday, 30 September, 2013 10:34 AM To: t10 at t10.org Subject: VERIFY & how the data got into the cache Unless I misheard them, WD engineers beg to differ with the following comments in the "4.15 specs for read operation" thread: <> For each LBA accessed by a read operation that is a verify operation, the device server shall perform a read cache operation only if: a) the logical block data in the cache for that LBA is the result of a read medium operation; and b) no subsequent write operation has been processed for that LBA. RE: It doesn't matter how the cache got the data. If there is more recent data in the cache, all verify operations need to force that data to media before performing the verify medium operation. <> How the data got into the cache very much matters (or so my experts tell me). For this reason, WD engineering sees the current 4.15 requirements as being fixated on the wrong thing. VERIFY commands are required to use data that is read from the medium. If the cache contains data that is newer then: 1. that data must be written to the medium, 2. the cache must be invalidated, and 3. the data must be read from the medium (and stored in cache if so desired). Any specification that says otherwise is misleading the reader. It is not acceptable to write the newer cache data to the medium and then use the cache contents without first reading the medium, unless the goal of the letter ballot changes is to negate the first sentence in the SBC-2 definition of VERIFY ... to whit: "The VERIFY (10) command (see table 53) requests that the device server verify the specified logical block(s) on the medium." Furthermore, the "newer data in cache" issue should be covered by b) in the WD proposed wording. All the best, .Ralph