From lohmeyer at t10.org  Mon Dec  1 10:34:54 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Mon, 01 Dec 2008 11:34:54 -0700
Subject: Hank Meyer
Message-ID: <mailman.985.1441607339.22514.t10@sandbox.t10.org>

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

Hank Meyer, a SCSI pioneer passed away November 14th. When I first met Hank
in 1981, he was Marketing Director at Shugart Associates; he was promoting
the Shugart Associates System Interface (SASI). As many of you already know,
SASI was the basis for SCSI. Needless to say, Hank was successful in his
assignment!
Hank's obituary is at:
 
<http://www.instantriverside.com/riverside-ca-news/henry-meyer-staten-island-
pasadena-menifee-sun-city-hemet-san-jacinto-california-obituary/2008/11/19/>h
ttp://www.instantriverside.com/riverside-ca-news/henry-meyer-staten-island-pa
sadena-menifee-sun-city-hemet-san-jacinto-california-obituary/2008/11/19/
I will miss Hank.
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


From Gerry.Houlder at seagate.com  Mon Dec  1 14:40:43 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Mon, 1 Dec 2008 16:40:43 -0600
Subject: Primitive assignments for 08-015
Message-ID: <mailman.986.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
The partial and slumber phy power management proposal (08-015) needs to
assign codes for four new primitives. I have had private discussions with
several SAS experts to see if there are some preferred codes for these
assignments but no one had any recommnedations, so I am picking these
unassigned codes out of annex N:
PS_REQ (PARTIAL) K28.5	D07.3  D02.0  D04.7
PS_REQ (SLUMBER) K28.5	D07.3  D07.3  D07.3
PS_ACK		 K28.5	D16.7  D27.4  D30.0
PS_NAK		 K28.5	D24.0  D27.4  D02.0
My choice of codes is mostly random, just an attempt to maintain a large
hamming distance between primitives (like PS_ACK and PS_NAK) that we really
don't want to confuse with each other. I encourage anyone with better
suggestion to contact me within 3 weeks (so I can change the latest rev.
before posting it to T10 web site) or at least bring up your suggestions at
the January T10 meetings.
Thank you.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From daviburg at windows.microsoft.com  Mon Dec  1 23:02:59 2008
From: daviburg at windows.microsoft.com (David Burg)
Date: Mon, 1 Dec 2008 23:02:59 -0800
Subject: [MtFuji] SATA AN, Sleep power state and media arrival
 notification
Message-ID: <mailman.987.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* David Burg <daviburg at windows.microsoft.com>
*
Thank you for sharing your opinion, Katata-san.
Should a wording be added to the specification to make clear no event is
posted unless native queuing is used, when entering sleep mode?
With regards,
David.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Wednesday, November 26, 2008 6:54 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org; Michael Xing; Frank Shu; David Walp; Ope Aladekomo
Subject: Re: [MtFuji] SATA AN, Sleep power state and media arrival
notification
I apologize.
Hard Reset of SATA is SSP=0.
Best regards,
Keiji Katata
PIONEER CORP.
-----Original Message-----
From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com] On
Behalf Of keiji_katata at post.pioneer.co.jp
Sent: Tuesday, November 25, 2008 11:00 PM
To: mtfuji5 at avc-pioneer.com
Cc: t10 at t10.org; Michael Xing; Frank Shu; David Walp; Ope Aladekomo
Subject: Re: [MtFuji] SATA AN, Sleep power state and media arrival
notification
Hello David,
>The first set of questions is regarding the entry to sleep mode. Should a
>power state notification be generated?
Basically No. At the completion of the START/STOP UNIT command for the sleep,
drive should enter the sleep state, then host should use Hard Reset (SSP=1)
to
communicate with the drive again. You may refer page 502 of Fuji7 R111.
In the case of native queuing environment when GESN is queued, before
completion
of the START/STOP UNIT command for sleep, the queued GESN shall be executed
and
shall be finished. In this case, a power state notification will be
generated.
I think your understanding is correct. Sleep option of START/STOP UNIT
command
is designed to turn off the drive power by host. Many drives may have same
power
consumption on Standby and on Sleep. If you want less power consumption than
now, you may request lower power consumption of Standby mode.
Or host may actually remove the power from drive. This case door of the drive
will not open.
Best regards,
Keiji Katata
PIONEER CORP.
David Burg <daviburg at windows.microsoft.com>@avc-pioneer.com on 2008/11/21
18:22:46
mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
$BAw?.<T(B:	  owner-mtfuji5 at avc-pioneer.com
$B08 at h(B:  "t10 at t10.org" <t10 at t10.org>, "mtfuji5 at avc-pioneer.com"
       <mtfuji5 at avc-pioneer.com>
cc:    Michael Xing <xiaoxing at microsoft.com>, Frank Shu
       <frankshu at windows.microsoft.com>, David Walp
<David.Walp at microsoft.com>,
       Ope Aladekomo <Ope.Aladekomo at microsoft.com>
$B7oL>(B:  [MtFuji] SATA AN, Sleep power state and media arrival
notification
Hi,
In a conference call with a SATA chipset manufacturer earlier this week the
manufacturer expressed difficulties in the implementation of SATA
Asynchronous
Notification (AN) because of the perceived lack of clarity in the handling of
sleep mode in combination with AN. As the manufacturer is not present on this
reflector or the Mt Fuji committee, I am relaying their issue. However the
chipset manufacturer is working with device manufacturer(s) from Mt Fuji
committee and expect that member(s) will be familiar and supportive of the
issue
resolution.
The chipset manufacturer is not clear what is the specified device behavior
when
the host issues a START/STOP UNIT command with parameters to request sleep
mode.
The first set of questions is regarding the entry to sleep mode. Should a
power
state notification be generated? If a power state notification is generated,
should AN be set? If a notification is generated and AN is set, will the
device
complete GESN from the host despite been in sleep mode? Does setting the
immediate bit change the behavior of event notification?
The second set of questions is regarding notification while in sleep mode. In
sleep mode, can the user insert an optical media? If the user can, can the
device generate a media arrival event? If so, can AN be posted and will the
device complete GESN from the host despite been in sleep mode?
If the user can insert a media but the device cannot generate a media arrival
event, the manufacturer is concerned by the user experience.
If the user cannot insert a media ? for instance if the device is actually
powered off in sleep and the door won$B!G(Bt open ? can PC vendors really
use this
mode for power saving without affecting the user experience?
Microsoft$B!G(Bs (not speaking on the manufacturer$B!G(Bs behalf now)
understanding of the
current Mt Fuji specification is that no event is generated *after* entering
sleep mode. So if the host issues a START/STOP UNIT command with parameters
to
request sleep mode with immediate bit set, the command completes, no event is
generated and no command but reset will work after the START/STOP UNIT
command
completes.
But if the host issues a START/STOP UNIT command with parameters to request
sleep mode with immediate bit NOT set, the command completes right away, no
power event is posted BUT if a GESN command is still processed while entering
sleep mode, Power Status Field is set to $B!H(B4h ? Sleep ? The device is
about to
enter sleep state$B!I(B, and AN is not set.
Microsoft$B!G(Bs understanding of the device sleep power mode is that it
should be
used only if the host itself (sleeps or) hibernates or powers off. Device
sleep
power mode should not be used while the host system is active, even if there
is
no optical device activity, because user interaction with the device would
not
work in sleep power mode (such as opening / closing the tray, inserting &
detection a new media). Instead, standby power mode needs to be used when the
host is active but the device is waiting.
Chipset manufacturer measured however that there is a non-negligible power
consumption saving by entering sleep mode in comparison to standby mode.
Could the device manufacturers on the reflector help clarify the source of
the
power consumption in standby mode. What could we do to avoid this power
consumption but still preserve the user experience of opening/closing door
and
detecting inserted media?
With regards,
David Burg.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roger_cummings at symantec.com  Tue Dec  2 07:26:57 2008
From: roger_cummings at symantec.com (Roger Cummings)
Date: Tue, 2 Dec 2008 08:26:57 -0700
Subject: Reminder - Hotel cutoff for January is FRIDAY THIS WEEK
Message-ID: <mailman.988.1441607339.22514.t10@sandbox.t10.org>

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

Folks,
 A quick reminder that the cutoff date for the room block for the
January T10 meetings in on Friday December 5 i.e. THIS WEEK. 
If you intend coming to any of the T10 meetings, please make a room
reservation by this date. Full details can be found at:
http://www.t10.org/ftp/t10/announce/ann-m089.pdf
The folks at the hotel tell me that at this time of year they are
typically full on Tuesday and Wednesday evenings each week. Therefore I
expect that they WILL release all of the unused portion of our room
block sometime during the week after the cutoff date at the latest, and
after that point you may be unable to stay at the hotel at all or the
rate will be much higher.  Note that we have  a VERY good rate for this
meeting @ $158 + tax, and that includes wired internet in your room. The
rate actually significantly lower than the for the previous meeting that
I hosted at this hotel.
Thanks to Matt Ball for already posting a reminder to the IEEE P1619
group. Would someone please also forward this reminder to the
appropriate STA reflector?
Regards,
Roger Cummings
Host
roger_cummings at symantec.com


From Elliott at hp.com  Tue Dec  2 08:17:33 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Tue, 2 Dec 2008 16:17:33 +0000
Subject: SAS-2 rev.15 Missing Sync lost message definition
Message-ID: <mailman.989.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
The SP receiver detects ALIGNs, TRAIN_DONEs, and Dwords and sends them as
ALIGN Received, TRAIN_DONE Received, and Dword Received messages.  See figure
35 on page 72.
If dword synchronization has been lost, however, it stops sending those
messages.  SP_DWS tells the SP receiver that dword synchronization has been
lost using the Sync Lost message.  See this wording on page 285:
"The ALIGN Received, Dword Received, and TRAIN_DONE Received messages are
only sent after the SP_DWS state machine has achieved dword synchronization."
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Samek
Sent: Thursday, November 27, 2008 1:46 PM
To: t10 at t10.org
Subject: SAS-2 rev.15 Missing Sync lost message definition
SP_DWS (6.9) defines a Sync Lost message sent by the SP_DWS state machine to
the SP receiver, however there is no definition anywhere what the SP receiver
should do with this message. Any suggestions?
Happy Thanksgiving
Samek Mokryn
President
Halstor Inc.
www.halstor.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gerry.Houlder at seagate.com  Tue Dec  2 14:36:46 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Tue, 2 Dec 2008 16:36:46 -0600
Subject: Questions on proposal 08-015
Message-ID: <mailman.990.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I have some questions on which I need advice of expander folks.
(1) 08-015r5 currently uses byte 13, bits 5 and 4, of the DISCOVER response
to report the Phy PS Condition field. It has been pointed out that is area
of the DISCOVER response is intended to line up with related fields in the
IDENTIFY address frame and should not be used for things that are not in
the IDENTIFY address frame. However we are adding capability bit(s) (there
is an outstanding question of whether we need one or two bits here) to the
IDENTIFY address frame.
(1a) If we add two bits for "capability" in the IDENTIFY address frame,
should those capability bits be reflected in the DISCOVER response?
(1b) Can we use the related two bit field for reporting Phy PS Condition
instead of the capability bits? Is there a need to report both the
capability bit field(s) in DISCOVER response as well as the actual Phy
Condition field?
(1c) Presuming I have to move the two bit Phy Condition field elsewhere, is
it important that the field also show up in the short format DISCOVER
response? Most of those fields overlap with the fields intended to overlap
with IDENTIFY address frame usage, so if this is important we may have to
break that overlap rule.
(1d) I am expecting to move the two bit Phy Condition field either to byte
34 bits 7 & 6 or byte 6 bits 7 & 6. Any preference on these?
(2) There is a need to create two bits to enable use of partial and slumber
on expander phys. The most obvious choice is the CONFIGURE GENERAL request.
Would byte 8 of CONFIGURE GENERAL be a good choice?
(3) It has been suggested that the Protocol Specific Port mode page is not
the right choice for controlling the target device. It has been suggested
that the two enable bits for slumber and partial phy power conditions
should be in the Enhanced Phy Control mode page (page 19h, subpage 3). I
think the best place is byte 19 bits 2 & 1. Any disagreement with this?
Please post opinions to me or to the reflector on these options by Dec. 12.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From samek at halstor.com  Tue Dec  2 16:12:57 2008
From: samek at halstor.com (Samek)
Date: Tue, 2 Dec 2008 19:12:57 -0500
Subject: SAS-2 rev.15 Missing Sync lost message definition
Message-ID: <mailman.991.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Samek" <samek at halstor.com>
*
It looks to me that the DWS Lost message does the same job. I can hardly see 
why there is a need for two.
These are however minor problems. I have much bigger problem with the fact 
that the comma characters are so sparse in the SAS protocol, resulting in a 
longer time to acquire synchronization, specially in the noisy environment 
(please note that with a lower bit energy in faster rates the SNR drops 
dramatically), which may lead to link resets - catastrophic from the 
performance point of view.
Samek Mokryn
President
HalStor Inc.
www.halstor.com
----- Original Message ----- 
From: "Elliott, Robert (Server Storage)" <Elliott at hp.com>
To: <t10 at t10.org>
Sent: Tuesday, December 02, 2008 11:17 AM
Subject: RE: SAS-2 rev.15 Missing Sync lost message definition
>* From the T10 Reflector (t10 at t10.org), posted by:
> * "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> *
> The SP receiver detects ALIGNs, TRAIN_DONEs, and Dwords and sends them as 
> ALIGN Received, TRAIN_DONE Received, and Dword Received messages.  See 
> figure 35 on page 72.
>
> If dword synchronization has been lost, however, it stops sending those 
> messages.  SP_DWS tells the SP receiver that dword synchronization has 
> been lost using the Sync Lost message.  See this wording on page 285:
>
> "The ALIGN Received, Dword Received, and TRAIN_DONE Received messages are 
> only sent after the SP_DWS state machine has achieved dword 
> synchronization."
>
> ________________________________
>
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Samek
> Sent: Thursday, November 27, 2008 1:46 PM
> To: t10 at t10.org
> Subject: SAS-2 rev.15 Missing Sync lost message definition
>
>
> SP_DWS (6.9) defines a Sync Lost message sent by the SP_DWS state machine 
> to the SP receiver, however there is no definition anywhere what the SP 
> receiver should do with this message. Any suggestions?
>
> Happy Thanksgiving
>
> Samek Mokryn
> President
> Halstor Inc.
> www.halstor.com
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
*
* 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 Dec  3 10:13:11 2008
From: Frederick.Knight at netapp.com (Knight, Frederick)
Date: Wed, 3 Dec 2008 13:13:11 -0500
Subject: T10 Thin Provisioning con-call reminder
Message-ID: <mailman.992.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Knight, Frederick" <Frederick.Knight at netapp.com>
*
Rev 6 of the TP proposal has been posted for tomorrows con-call:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-149r6.pdf
--------------------------------------------------------------
frederick knight has invited you to join a meeting on the Web, using
WebEx
Topic: CAP - Thin Provisioning
Date: Thursday, December 4, 2008
Time: 11:00 am, Pacific Standard Time (GMT -08:00, San Francisco )
Meeting number: 922 724 852
Meeting password: CAP-TP	   (CAP dash TP)
Please click the link below to see more information, or to join the
meeting.
NOTE: You do not need to register for a WebEx Account to attend this
meeting. Just click on the link below and use the Meeting password:
CAP-TP
https://netapp-meeting.webex.com/netapp-meeting/j.php?ED=110730597&UID=0
<https://netapp-meeting.webex.com/netapp-meeting/j.php?ED=110730597&UID=
0>
Teleconference:  1-888-765-3653
Toll Number (also International) - 303-218-2659
Conference ID - 5952226
To contact frederick knight,
send a message to this address: knight at netapp.com

*
* 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 Dec  3 10:32:44 2008
From: lohmeyer at t10.org (John Lohmeyer)
Date: Wed, 03 Dec 2008 11:32:44 -0700
Subject: Fwd: [incits-chairs] Action Requested: 2009 Nominations for
  the Annual INCITS Awards - Due Friday, February 20, 2009
Message-ID: <mailman.993.1441607339.22514.t10@sandbox.t10.org>

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

All,
The attached document explains how you can nominate someone for INCITS
awards. If there is someone you think deserves one of these awards, please
nominate them. I'll be glad to help you.
John
>From: "Barra, Lynn" <lbarra at itic.org>
>To: "incits-chairs at lyris.itic.org" <incits-chairs at lyris.itic.org>
>Date: Fri, 7 Nov 2008 19:46:57 -0700
>Subject: [incits-chairs] Action Requested: 2009 Nominations for the Annual
> INCITS Awards - Due Friday, February 20, 2009
> 
>
>To INCITS TC, TG, SG Officers and Executive Board Members ? 
> 
> 
>In preparation for the 2009 TC Officers Symposium being held April 20-21,
2009, in the Orlando, FL area, we are requesting members to submit
nominations for the annual awards to recognize the individual achievements of
members of the INCITS community.  Nominations in seven of the eight
categories are invited from all members (please see the attached notification
letter).  Chairs: Please ensure this information is distributed to your
committee.
> 
>All members are encouraged to submit nominations.  They should be sent to
Lynn Barra (lbarra at itic.org) at the INCITS Secretariat not later than Friday,
February 20, 2009. 
> 
>Each nomination must include the candidate's name, address and email, the
award sought for the candidate, and details of the candidate's achievements
based on the criteria for nomination. 
> 
>If you have any questions, please contact the Secretariat.
> 
>
> 
>
><InterNational">http://www.incits.org/>InterNational Committee for Information Technology
Standards<http://www.incits.org/&gt; 
>INCITS Secretariat, Information Technology Industry Council (ITI)	
>1250 Eye St. NW, Suite 200, Washington, DC 20005   
>
>Notice 
>This message is intended exclusively for the individual or entity to which
it is addressed. This mailing list may not be used for unlawful purposes. All
postings should be relevant, but ITI accepts no responsibility for any
posting and may terminate access to any subscriber violating any policies of
the Association. Please review the INCITS Anti-Trust Guidelines at
<http://www.incits.org/inatrust.htm">http://www.incits.org/inatrust.htm>http://www.incits.org/inatrust.htm 
>
>Please be advised that replying to this message goes to the sender. If you
wish to send a reply to all on the list, please respond with "Reply All". If
you have received this message in error, please notify the sender immediately
by e-mail and delete all copies of the message. 
>
>---
--
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


From Elliott at hp.com  Wed Dec  3 11:30:22 2008
From: Elliott at hp.com (Elliott, Robert (Server Storage))
Date: Wed, 3 Dec 2008 19:30:22 +0000
Subject: SAS-2 rev.15 Missing Sync lost message definition
Message-ID: <mailman.994.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
*
DWS Lost is the name of a message going to SP, not the SP receiver.  They're
sent at similar times and possibly could be made identical.
Although the SAS standard (like most other serial protocols) only requires a
BER of 10^12 (which is one error every 2.77 min per one direction of a
physical link at 6 Gbps), a system generating anywhere near those number of
errors will have so many other problems it won't be viable.  Dword
synchronization mainly just happens once during speed negotiation. Most of
the time is spent finding the center of the bits; once done, identifying the
dword boundary by finding a comma is easy.
-----Original Message-----
From: Samek [mailto:samek at halstor.com]
Sent: Tuesday, December 02, 2008 6:13 PM
To: Elliott, Robert (Server Storage); t10 at t10.org
Subject: Re: SAS-2 rev.15 Missing Sync lost message definition
It looks to me that the DWS Lost message does the same job. I can hardly see
why there is a need for two.
These are however minor problems. I have much bigger problem with the fact
that the comma characters are so sparse in the SAS protocol, resulting in a
longer time to acquire synchronization, specially in the noisy environment
(please note that with a lower bit energy in faster rates the SNR drops
dramatically), which may lead to link resets - catastrophic from the
performance point of view.
Samek Mokryn
President
HalStor Inc.
www.halstor.com
----- Original Message -----
From: "Elliott, Robert (Server Storage)" <Elliott at hp.com>
To: <t10 at t10.org>
Sent: Tuesday, December 02, 2008 11:17 AM
Subject: RE: SAS-2 rev.15 Missing Sync lost message definition
>* From the T10 Reflector (t10 at t10.org), posted by:
> * "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> *
> The SP receiver detects ALIGNs, TRAIN_DONEs, and Dwords and sends them as
> ALIGN Received, TRAIN_DONE Received, and Dword Received messages.  See
> figure 35 on page 72.
>
> If dword synchronization has been lost, however, it stops sending those
> messages.  SP_DWS tells the SP receiver that dword synchronization has
> been lost using the Sync Lost message.  See this wording on page 285:
>
> "The ALIGN Received, Dword Received, and TRAIN_DONE Received messages are
> only sent after the SP_DWS state machine has achieved dword
> synchronization."
>
> ________________________________
>
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Samek
> Sent: Thursday, November 27, 2008 1:46 PM
> To: t10 at t10.org
> Subject: SAS-2 rev.15 Missing Sync lost message definition
>
>
> SP_DWS (6.9) defines a Sync Lost message sent by the SP_DWS state machine
> to the SP receiver, however there is no definition anywhere what the SP
> receiver should do with this message. Any suggestions?
>
> Happy Thanksgiving
>
> Samek Mokryn
> President
> Halstor Inc.
> www.halstor.com
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Brian.Day at lsi.com  Wed Dec  3 13:12:53 2008
From: Brian.Day at lsi.com (Day, Brian)
Date: Wed, 3 Dec 2008 14:12:53 -0700
Subject: Questions on proposal 08-015
Message-ID: <mailman.995.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <Brian.Day at lsi.com>
*
Hi Gerry....
Please see below with BD>>
Brian Day
LSI Corp.
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Tuesday, December 02, 2008 3:37 PM
To: t10 at t10.org
Subject: Questions on proposal 08-015
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I have some questions on which I need advice of expander folks.
(1) 08-015r5 currently uses byte 13, bits 5 and 4, of the DISCOVER response
to report the Phy PS Condition field. It has been pointed out that is area of
the DISCOVER response is intended to line up with related fields in the
IDENTIFY address frame and should not be used for things that are not in the
IDENTIFY address frame. However we are adding capability bit(s) (there is an
outstanding question of whether we need one or two bits here) to the IDENTIFY
address frame.
BD>> This area isn't intended to exactly line up byte-for-byte with the
received IDENTIFY frame, so having the current power mode of the phy reported
here similar to the NEGOTIATED LINK RATE seems appropriate.  This also allows
the short format for DISCOVER LIST response to work the same (re question 1c
and 1d below).
(1a) If we add two bits for "capability" in the IDENTIFY address frame,
should those capability bits be reflected in the DISCOVER response?
BD>> The expander capabilities reporting have already been proposed and
discussed some at Nov meeting for proposal 08-420.  A take-away from that
discussion was that Brad will be adding the "attached" version of the
cababilities bits of the received IDENTIFY frame.
(1b) Can we use the related two bit field for reporting Phy PS Condition
instead of the capability bits? Is there a need to report both the capability
bit field(s) in DISCOVER response as well as the actual Phy Condition field?
BD>>  We want capable, enabled, and current state.  Should we just
incorporate the current power condition reporting into 08-420, and remove
|from 08-15?  That might be nice to keep all the SMP changes in one proposal.
(1c) Presuming I have to move the two bit Phy Condition field elsewhere, is
it important that the field also show up in the short format DISCOVER
response? Most of those fields overlap with the fields intended to overlap
with IDENTIFY address frame usage, so if this is important we may have to
break that overlap rule.
(1d) I am expecting to move the two bit Phy Condition field either to byte
34 bits 7 & 6 or byte 6 bits 7 & 6. Any preference on these?
(2) There is a need to create two bits to enable use of partial and slumber
on expander phys. The most obvious choice is the CONFIGURE GENERAL request.
Would byte 8 of CONFIGURE GENERAL be a good choice?
BD>> 08-420 has already proposed PHY CONTROL... since we need to control each
phy individually.
(3) It has been suggested that the Protocol Specific Port mode page is not
the right choice for controlling the target device. It has been suggested
that the two enable bits for slumber and partial phy power conditions should
be in the Enhanced Phy Control mode page (page 19h, subpage 3). I think the
best place is byte 19 bits 2 & 1. Any disagreement with this?
Please post opinions to me or to the reflector on these options by Dec. 12.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From pvstamwitz at amcc.com  Wed Dec  3 13:50:42 2008
From: pvstamwitz at amcc.com (Paul Von Stamwitz)
Date: Wed, 3 Dec 2008 13:50:42 -0800
Subject: SAS 2.1 connector considerations
Message-ID: <mailman.996.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Paul Von Stamwitz" <pvstamwitz at amcc.com>
*
Alvin, Here are my 2 cents.
First, my assumptions:
1. We should provide an active copper solution for 2.1 to support 20-25m
cables.
2. I don't see a need for optical for 6Gb SAS since the vast majority
(if not all) of the applications will be handled by the passive/active
copper cables.
3. I do see the need for optical at 12Gb, since active copper may not be
able to achieve the 25m distance.
4. Lane density (# of lanes per sq. inch) is more important for internal
than external.
With these in mind, I am wary of defining a new connector for optical in
2.1. We have a limited timeframe which will probably require us to use
existing solutions such as the current 8088 or QSFP which have their
drawbacks (lack of sidebands, size of footprint, etc.) If we do choose a
new connector for 2.1, I believe we will be shackled with it for 3.0,
because of backward compatibility and to avoid confusing the customer
base by changing cables too often.
Therefore, I recommend the following:
1. We table optical considerations until 3.0 on the assumption that
there will be a new connector for copper/optical.
2. For 2.1 we adopt 08-358 to add active power to the existing Mini SAS
4x and live with the keying confusion until 3.0.
3. I don't think we need an external connector with greater than 4
lanes, but if we do, we should use the 68-circuit 8088 (Mini SAS 8x)with
appropriate sidebands instead of keys. The primary usage model should be
8x-to-8x (i.e. let's try to avoid the Y-cable to two Mini SAS 4x.) I
also don't think we need the modular approach for external (e.g.
SFF-8644 as proposed in 08-455). Many applications would use a hybrid
modular plug to Mini SAS 4x, so the sidebands on the modular side would
have to match the keying on the Mini SAS side. And, I don't think we
have the lane density issue for external that we have for internal. 
4. So, for internal, we should consider the modular approach (e.g.
SFF-8643 in 08-455). The currently defined sidebands should be used (but
the pinouts can be made less confusing) and they should be duplicated on
every 4x connection.
In summary, I think optical should wait for 3.0. We should also avoid
major changes to the external connectors for 2.1 and make sure the
solutions we make for 3.0 address all the issues. Any changes to the
external connections should be "variations on the them", such as active
mini SAS 4x, mini SAS 8x, etc. For internal, a narrower version of the
mini SAS 4i by stacking 2 lanes over 2, while maintaining the same
sidebands per 4 lanes, makes good sense.
-Paul 
________________________________
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Alvin.Cox at seagate.com
Sent: Monday, November 24, 2008 2:25 PM
To: t10 at t10.org
Subject: SAS 2.1 connector considerations
Feedback from users would help to narrow the selection field and number
of proposals to better fit the application model. In addition to the
posting by Alvin Cox regarding the input from the November t10 meeting,
a few opinions would be extremely helpful. Please consider both internal
and external applications. 
08-453 <http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-453r0.pdf&gt;;  
Is a modular design favored over a set number of connections? 
	This would likely consist of 4x blocks and could allow for
multiple cables or different single cables that have the 4x, 8x, 12x,
16x configurations. 
	Trade-off of modular may be encountered due to area. 
	Suggestions for sideband support? 
		Separate module? 
		Include in one module? 
		Duplicate on all modules? 
			Partial or all lines? 
Sidebands? 
	How many required for internal and external? 
	Does external provide more information than just cable power and
type? 
Power requirements? 
	How much power is required for a 16x configuration? 
		Copper 
		Optical 
	What voltage and current? 
		Cable perspective 
		User perspective 
Alvin Cox
Seagate Technology, LLC
Office 405-392-3738
Cell 405-206-4809
E-Mail	alvin.cox at seagate.com
--------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and contains information that
is confidential and proprietary to Applied Micro Circuits Corporation or its
subsidiaries. It is to be used solely for the purpose of furthering the
parties' business relationship. All unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gerry.Houlder at seagate.com  Wed Dec  3 15:30:00 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Wed, 3 Dec 2008 17:30:00 -0600
Subject: Questions on proposal 08-015
Message-ID: <mailman.997.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
Thanks for your reply, Brian.
I like the idea of keeping all of the SMP function changes in the same
document. Since you have started 08-420 for this purpose, that would be a
good place to bundle the SMP PHY CONTROL, SMP DISCOVER, and SMP DISCOVER
LIST (if changes to short discover version is needed). I will add a
placeholder referring to 08-420 for those details.
I will continue to describe the mode page changes (for the target device)
in 08-015.
	     "Day, Brian"						   
	     <Brian.Day at lsi.co						   
	     m> 							To 
	     No Phone Info	       "Gerry.Houlder at seagate.com"	   
	     Available		       <Gerry.Houlder at seagate.com>,	   
				       "t10 at t10.org" <t10 at t10.org>	   
									cc 
	     12/03/2008 03:12						   
	     PM 						   Subject 
				       RE: Questions on proposal 08-015    
Hi Gerry....
Please see below with BD>>
Brian Day
LSI Corp.
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of
Gerry.Houlder at seagate.com
Sent: Tuesday, December 02, 2008 3:37 PM
To: t10 at t10.org
Subject: Questions on proposal 08-015
* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
I have some questions on which I need advice of expander folks.
(1) 08-015r5 currently uses byte 13, bits 5 and 4, of the DISCOVER response
to report the Phy PS Condition field. It has been pointed out that is area
of the DISCOVER response is intended to line up with related fields in the
IDENTIFY address frame and should not be used for things that are not in
the IDENTIFY address frame. However we are adding capability bit(s) (there
is an outstanding question of whether we need one or two bits here) to the
IDENTIFY address frame.
BD>> This area isn't intended to exactly line up byte-for-byte with the
received IDENTIFY frame, so having the current power mode of the phy
reported here similar to the NEGOTIATED LINK RATE seems appropriate.  This
also allows the short format for DISCOVER LIST response to work the same
(re question 1c and 1d below).
(1a) If we add two bits for "capability" in the IDENTIFY address frame,
should those capability bits be reflected in the DISCOVER response?
BD>> The expander capabilities reporting have already been proposed and
discussed some at Nov meeting for proposal 08-420.  A take-away from that
discussion was that Brad will be adding the "attached" version of the
cababilities bits of the received IDENTIFY frame.
(1b) Can we use the related two bit field for reporting Phy PS Condition
instead of the capability bits? Is there a need to report both the
capability bit field(s) in DISCOVER response as well as the actual Phy
Condition field?
BD>>  We want capable, enabled, and current state.  Should we just
incorporate the current power condition reporting into 08-420, and remove
|from 08-15?  That might be nice to keep all the SMP changes in one
proposal.
(1c) Presuming I have to move the two bit Phy Condition field elsewhere, is
it important that the field also show up in the short format DISCOVER
response? Most of those fields overlap with the fields intended to overlap
with IDENTIFY address frame usage, so if this is important we may have to
break that overlap rule.
(1d) I am expecting to move the two bit Phy Condition field either to byte
34 bits 7 & 6 or byte 6 bits 7 & 6. Any preference on these?
(2) There is a need to create two bits to enable use of partial and slumber
on expander phys. The most obvious choice is the CONFIGURE GENERAL request.
Would byte 8 of CONFIGURE GENERAL be a good choice?
BD>> 08-420 has already proposed PHY CONTROL... since we need to control
each phy individually.
(3) It has been suggested that the Protocol Specific Port mode page is not
the right choice for controlling the target device. It has been suggested
that the two enable bits for slumber and partial phy power conditions
should be in the Enhanced Phy Control mode page (page 19h, subpage 3). I
think the best place is byte 19 bits 2 & 1. Any disagreement with this?
Please post opinions to me or to the reflector on these options by Dec. 12.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From daryl.teo at intel.com  Wed Dec  3 18:11:15 2008
From: daryl.teo at intel.com (Teo, Daryl)
Date: Wed, 3 Dec 2008 19:11:15 -0700
Subject: Question regarding STP Wide Port arbitration rule
Message-ID: <mailman.998.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Teo, Daryl" <daryl.teo at intel.com>
*
Hi
I'm seeking clarification on a particular arbitration rule concerning wide
STP initiator and target ports. Section 7.18.5 (sas2r15) states that 
"While a wide STP initiator port is waiting for a response to a connection
request to an STP target port, a SAS phy in the STP initiator port shall not
reject an incoming connection request from that STP target port with
OPEN_REJECT (RETRY) because the SAS port containing that SAS phy needs an
outgoing connection request to be accepted."
and
"While a wide STP target port is waiting for a response to a connection
request or has established a connection to an STP initiator port, the wide
STP target port shall 
a) reject incoming connection requests from that STP initiator port with
OPEN_REJECT (RETRY);"
Do the above paragraphs imply that if a phy in the STP initiator port and a
phy in the STP target port are simultaneously arbitrating on the same link,
both phys are expected to ignore the arbitration fairness rule as defined in
section 7.13.3? 
There are a couple of issues with the above scenario:
1) There is nothing defined in SL_CC1:ArbSel to SL_CC2:Selected state
transition (section 7.15.4.3.3) for an STP initiator/target to ignore the
arbitration fairness check;
2) After transmitting the OPEN_REJECT, the target transitions to SL_CC0:Idle
state and would need to resend the OPEN Addr Frame to retry the connection
request. However, if the initiator detects a loss in arbitration and sends an
OPEN_ACCEPT while the target is in SL_CC0:Idle state, the target will miss
the OPEN_ACCEPT. This results in a situation where the target remains in
SL_CC1:ArbSel state (till Open timeout followed by Break timeout occurs) and
the initiator is stuck in SL_CC3:Connected state.
It seems that the description in those paragraphs will make sense if both
connection requests are occurring on different physical links.
Daryl Teo
Intel Corp
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From MOverby at nvidia.com  Fri Dec  5 15:23:33 2008
From: MOverby at nvidia.com (Mark Overby)
Date: Fri, 5 Dec 2008 15:23:33 -0800
Subject: Sat meeting
Message-ID: <mailman.999.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Mark Overby <MOverby at nvidia.com>
*
I apologize. I sent out an email this morning but it didn't go out. I had to
make an urgent trip to the physician with a broken bone in my foot.
Sent from blackberry
-----------------------------------------------------------------------------
------
This email message is for the sole use of the intended recipient(s) and may
contain
confidential information.  Any unauthorized review, use, disclosure or
distribution
is prohibited.	If you are not the intended recipient, please contact the
sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------
------
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From samek at halstor.com  Sat Dec  6 10:05:07 2008
From: samek at halstor.com (Samek)
Date: Sat, 6 Dec 2008 13:05:07 -0500
Subject: SAS-2 rev.15 Missing Sync lost message definition
Message-ID: <mailman.1000.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Samek" <samek at halstor.com>
*
In a real life, due to various factors, the loss of sync will be a common 
occurence and due to the infriquent primitives may cause link resets, which 
in SAS/SATA cases are really bad. By the way, dword synchronization may 
happen any time, not only during a speed negotiations.
Samek Mokryn
President
HalStor Inc.
www.halstor.com
----- Original Message ----- 
From: "Elliott, Robert (Server Storage)" <Elliott at hp.com>
To: <t10 at t10.org>
Sent: Wednesday, December 03, 2008 2:30 PM
Subject: RE: SAS-2 rev.15 Missing Sync lost message definition
>* From the T10 Reflector (t10 at t10.org), posted by:
> * "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> *
> DWS Lost is the name of a message going to SP, not the SP receiver. 
> They're sent at similar times and possibly could be made identical.
>
> Although the SAS standard (like most other serial protocols) only requires 
> a BER of 10^12 (which is one error every 2.77 min per one direction of a 
> physical link at 6 Gbps), a system generating anywhere near those number 
> of errors will have so many other problems it won't be viable.  Dword 
> synchronization mainly just happens once during speed negotiation. Most of 
> the time is spent finding the center of the bits; once done, identifying 
> the dword boundary by finding a comma is easy.
>
>
>
> -----Original Message-----
> From: Samek [mailto:samek at halstor.com]
> Sent: Tuesday, December 02, 2008 6:13 PM
> To: Elliott, Robert (Server Storage); t10 at t10.org
> Subject: Re: SAS-2 rev.15 Missing Sync lost message definition
>
> It looks to me that the DWS Lost message does the same job. I can hardly 
> see
> why there is a need for two.
> These are however minor problems. I have much bigger problem with the fact
> that the comma characters are so sparse in the SAS protocol, resulting in 
> a
> longer time to acquire synchronization, specially in the noisy environment
> (please note that with a lower bit energy in faster rates the SNR drops
> dramatically), which may lead to link resets - catastrophic from the
> performance point of view.
>
> Samek Mokryn
> President
> HalStor Inc.
> www.halstor.com
>
>
>
> ----- Original Message -----
> From: "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> To: <t10 at t10.org>
> Sent: Tuesday, December 02, 2008 11:17 AM
> Subject: RE: SAS-2 rev.15 Missing Sync lost message definition
>
>
>>* From the T10 Reflector (t10 at t10.org), posted by:
>> * "Elliott, Robert (Server Storage)" <Elliott at hp.com>
>> *
>> The SP receiver detects ALIGNs, TRAIN_DONEs, and Dwords and sends them as
>> ALIGN Received, TRAIN_DONE Received, and Dword Received messages.  See
>> figure 35 on page 72.
>>
>> If dword synchronization has been lost, however, it stops sending those
>> messages.  SP_DWS tells the SP receiver that dword synchronization has
>> been lost using the Sync Lost message.  See this wording on page 285:
>>
>> "The ALIGN Received, Dword Received, and TRAIN_DONE Received messages are
>> only sent after the SP_DWS state machine has achieved dword
>> synchronization."
>>
>> ________________________________
>>
>> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Samek
>> Sent: Thursday, November 27, 2008 1:46 PM
>> To: t10 at t10.org
>> Subject: SAS-2 rev.15 Missing Sync lost message definition
>>
>>
>> SP_DWS (6.9) defines a Sync Lost message sent by the SP_DWS state machine
>> to the SP receiver, however there is no definition anywhere what the SP
>> receiver should do with this message. Any suggestions?
>>
>> Happy Thanksgiving
>>
>> Samek Mokryn
>> President
>> Halstor Inc.
>> www.halstor.com
>>
>> *
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
*
* 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 Dec  6 23:00:50 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 7 Dec 2008 00:00:50 -0700
Subject: Recent T10 documents uploaded since 2008/11/30
Message-ID: <mailman.1001.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC - Thin Provisioning
(by: Frederick Knight)
T10/08-149r6   Uploaded: 2008/12/03   284256 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-149r6.pdf
UAS Clause 6 (Usage)
(by: Curtis Stevens)
T10/08-282r3   Uploaded: 2008/12/04   132191 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-282r3.pdf
ADT-2:	Internet ADT (iADT)
(by: Paul Suhler)
T10/08-409r3   Uploaded: 2008/12/01   351018 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-409r3.pdf
SBC-3/SPC-4 : Adding a Protection Information Interval
(by: George Penokie)
T10/08-415r3   Uploaded: 2008/12/02   347468 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-415r3.pdf
SPC-4: IKEv2-SCSI Authentication
(by: David L. Black)
T10/08-423r3   Uploaded: 2008/12/01   72880 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-423r3.pdf
SAT-2 ATA collateral abort modifications
(by: William Martin)
T10/08-451r1   Uploaded: 2008/12/03   1286307 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-451r1.pdf
Agenda for T10 Meeting #89 January 2009
(by: John Lohmeyer)
T10/08-458r2   Uploaded: 2008/12/01   61604 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-458r2.pdf
Project Proposal: SES-3 Project Proposal
(by: Frederick Knight)
T10/09-009r0   Uploaded: 2008/12/03   20919 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-009r0.pdf
Minutes of ADI teleconference 3 December 2008
(by: Curtis Ballard)
T10/09-010r0   Uploaded: 2008/12/03   62976 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-010r0.doc
Minutes of ADI teleconference 3 December 2008
(by: Curtis Ballard)
T10/09-010r0   Uploaded: 2008/12/03   158354 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-010r0.pdf
Working Drafts
--------------
(Report generated on 2008/12/07 at 00:00:50)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Brian.Day at lsi.com  Sun Dec  7 18:04:32 2008
From: Brian.Day at lsi.com (Day, Brian)
Date: Sun, 7 Dec 2008 19:04:32 -0700
Subject: SAS-2 rev.15 Missing Sync lost message definition
Message-ID: <mailman.1002.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <Brian.Day at lsi.com>
*
Hello Samek...
I'm not sure I agree with SAS being specified with too infrequent primitives
relative to loss of sync.
SAS 2 defines an ALIGN primitive to be sent every 3.4 us (approximately... it
is every 128 dwords at 1.5Gbps).
The DWS Reset Timeout is specified as 1 ms.
So assuming link multiplexxing is not enabled, from the loss of sync
(regardless of how often this may occur due a particular system's BER), there
are almost 300	ALIGNs permitting a device to recover sync during the DWS
Reset Timeout period before it gives up and performs the link reset.
Brian Day
LSI Corporation
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Samek
Sent: Saturday, December 06, 2008 11:05 AM
To: Elliott, Robert (Server Storage); t10 at t10.org
Subject: Re: SAS-2 rev.15 Missing Sync lost message definition
* From the T10 Reflector (t10 at t10.org), posted by:
* "Samek" <samek at halstor.com>
*
In a real life, due to various factors, the loss of sync will be a common
occurence and due to the infriquent primitives may cause link resets, which
in SAS/SATA cases are really bad. By the way, dword synchronization may
happen any time, not only during a speed negotiations.
Samek Mokryn
President
HalStor Inc.
www.halstor.com
----- Original Message -----
From: "Elliott, Robert (Server Storage)" <Elliott at hp.com>
To: <t10 at t10.org>
Sent: Wednesday, December 03, 2008 2:30 PM
Subject: RE: SAS-2 rev.15 Missing Sync lost message definition
>* From the T10 Reflector (t10 at t10.org), posted by:
> * "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> *
> DWS Lost is the name of a message going to SP, not the SP receiver.
> They're sent at similar times and possibly could be made identical.
>
> Although the SAS standard (like most other serial protocols) only
> requires a BER of 10^12 (which is one error every 2.77 min per one
> direction of a physical link at 6 Gbps), a system generating anywhere
> near those number of errors will have so many other problems it won't
> be viable.  Dword synchronization mainly just happens once during
> speed negotiation. Most of the time is spent finding the center of the
> bits; once done, identifying the dword boundary by finding a comma is easy.
>
>
>
> -----Original Message-----
> From: Samek [mailto:samek at halstor.com]
> Sent: Tuesday, December 02, 2008 6:13 PM
> To: Elliott, Robert (Server Storage); t10 at t10.org
> Subject: Re: SAS-2 rev.15 Missing Sync lost message definition
>
> It looks to me that the DWS Lost message does the same job. I can
> hardly see why there is a need for two.
> These are however minor problems. I have much bigger problem with the
> fact that the comma characters are so sparse in the SAS protocol,
> resulting in a longer time to acquire synchronization, specially in
> the noisy environment (please note that with a lower bit energy in
> faster rates the SNR drops dramatically), which may lead to link
> resets - catastrophic from the performance point of view.
>
> Samek Mokryn
> President
> HalStor Inc.
> www.halstor.com
>
>
>
> ----- Original Message -----
> From: "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> To: <t10 at t10.org>
> Sent: Tuesday, December 02, 2008 11:17 AM
> Subject: RE: SAS-2 rev.15 Missing Sync lost message definition
>
>
>>* From the T10 Reflector (t10 at t10.org), posted by:
>> * "Elliott, Robert (Server Storage)" <Elliott at hp.com>
>> *
>> The SP receiver detects ALIGNs, TRAIN_DONEs, and Dwords and sends
>>them as  ALIGN Received, TRAIN_DONE Received, and Dword Received
>>messages.  See  figure 35 on page 72.
>>
>> If dword synchronization has been lost, however, it stops sending
>> those messages.  SP_DWS tells the SP receiver that dword
>> synchronization has been lost using the Sync Lost message.  See this
wording on page 285:
>>
>> "The ALIGN Received, Dword Received, and TRAIN_DONE Received messages
>> are only sent after the SP_DWS state machine has achieved dword
>> synchronization."
>>
>> ________________________________
>>
>> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Samek
>> Sent: Thursday, November 27, 2008 1:46 PM
>> To: t10 at t10.org
>> Subject: SAS-2 rev.15 Missing Sync lost message definition
>>
>>
>> SP_DWS (6.9) defines a Sync Lost message sent by the SP_DWS state
>> machine to the SP receiver, however there is no definition anywhere
>> what the SP receiver should do with this message. Any suggestions?
>>
>> Happy Thanksgiving
>>
>> Samek Mokryn
>> President
>> Halstor Inc.
>> www.halstor.com
>>
>> *
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Brian.Day at lsi.com  Mon Dec  8 08:00:00 2008
From: Brian.Day at lsi.com (Day, Brian)
Date: Mon, 8 Dec 2008 09:00:00 -0700
Subject: Question regarding STP Wide Port arbitration rule
Message-ID: <mailman.1003.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Day, Brian" <Brian.Day at lsi.com>
*
Hello Daryl...
Please see comments below with BD>>
Brian Day
LSI Corporation
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Teo, Daryl
Sent: Wednesday, December 03, 2008 7:11 PM
To: t10 at t10.org
Subject: Question regarding STP Wide Port arbitration rule
* From the T10 Reflector (t10 at t10.org), posted by:
* "Teo, Daryl" <daryl.teo at intel.com>
*
Hi
I'm seeking clarification on a particular arbitration rule concerning wide
STP initiator and target ports. Section 7.18.5 (sas2r15) states that
"While a wide STP initiator port is waiting for a response to a connection
request to an STP target port, a SAS phy in the STP initiator port shall not
reject an incoming connection request from that STP target port with
OPEN_REJECT (RETRY) because the SAS port containing that SAS phy needs an
outgoing connection request to be accepted."
BD>> It is somewhat important to note that this statement does not require an
initiator to never send OPEN_REJECT (RETRY)... it is specifically requiring
an initiator implementation to not be dependent on it's outgoing connection
request to be honored before accepting connections to that target.  It may
still issue OPEN_REJECT for other (temporary) reasons.
and
"While a wide STP target port is waiting for a response to a connection
request or has established a connection to an STP initiator port, the wide
STP target port shall
a) reject incoming connection requests from that STP initiator port with
OPEN_REJECT (RETRY);"
Do the above paragraphs imply that if a phy in the STP initiator port and a
phy in the STP target port are simultaneously arbitrating on the same link,
both phys are expected to ignore the arbitration fairness rule as defined in
section 7.13.3?
BD>>  If my memory is correct (which I'm not necessarily claiming it is :) ),
the original intention was to only reject on different links from where the
outstanding connection request is.  You are correct in pointing out the
wording doesn't quite say this.  Perhaps we can change it in the upcoming SPL
spec.
I don't remember an intention to ignore the normal fairness rules when OPENs
crossed.
There are a couple of issues with the above scenario:
1) There is nothing defined in SL_CC1:ArbSel to SL_CC2:Selected state
transition (section 7.15.4.3.3) for an STP initiator/target to ignore the
arbitration fairness check;
2) After transmitting the OPEN_REJECT, the target transitions to SL_CC0:Idle
state and would need to resend the OPEN Addr Frame to retry the connection
request. However, if the initiator detects a loss in arbitration and sends an
OPEN_ACCEPT while the target is in SL_CC0:Idle state, the target will miss
the OPEN_ACCEPT. This results in a situation where the target remains in
SL_CC1:ArbSel state (till Open timeout followed by Break timeout occurs) and
the initiator is stuck in SL_CC3:Connected state.
It seems that the description in those paragraphs will make sense if both
connection requests are occurring on different physical links.
Daryl Teo
Intel Corp
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From daryl.teo at intel.com  Mon Dec  8 10:25:08 2008
From: daryl.teo at intel.com (Teo, Daryl)
Date: Mon, 8 Dec 2008 11:25:08 -0700
Subject: Question regarding STP Wide Port arbitration rule
Message-ID: <mailman.1004.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Teo, Daryl" <daryl.teo at intel.com>
*
Thanks for your response, Brian. I agree that the wording should be changed
in the spec if the original intent is targeted at different links as I've
already seen this rule interpreted as worded somewhere. 
Daryl Teo
Intel Corp
-----Original Message-----
From: Day, Brian [mailto:Brian.Day at lsi.com] 
Sent: Monday, December 08, 2008 9:00 AM
To: Teo, Daryl; t10 at t10.org
Subject: RE: Question regarding STP Wide Port arbitration rule
Hello Daryl...
Please see comments below with BD>>
Brian Day
LSI Corporation
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Teo, Daryl
Sent: Wednesday, December 03, 2008 7:11 PM
To: t10 at t10.org
Subject: Question regarding STP Wide Port arbitration rule
* From the T10 Reflector (t10 at t10.org), posted by:
* "Teo, Daryl" <daryl.teo at intel.com>
*
Hi
I'm seeking clarification on a particular arbitration rule concerning wide
STP initiator and target ports. Section 7.18.5 (sas2r15) states that
"While a wide STP initiator port is waiting for a response to a connection
request to an STP target port, a SAS phy in the STP initiator port shall not
reject an incoming connection request from that STP target port with
OPEN_REJECT (RETRY) because the SAS port containing that SAS phy needs an
outgoing connection request to be accepted."
BD>> It is somewhat important to note that this statement does not require an
initiator to never send OPEN_REJECT (RETRY)... it is specifically requiring
an initiator implementation to not be dependent on it's outgoing connection
request to be honored before accepting connections to that target.  It may
still issue OPEN_REJECT for other (temporary) reasons.
and
"While a wide STP target port is waiting for a response to a connection
request or has established a connection to an STP initiator port, the wide
STP target port shall
a) reject incoming connection requests from that STP initiator port with
OPEN_REJECT (RETRY);"
Do the above paragraphs imply that if a phy in the STP initiator port and a
phy in the STP target port are simultaneously arbitrating on the same link,
both phys are expected to ignore the arbitration fairness rule as defined in
section 7.13.3?
BD>>  If my memory is correct (which I'm not necessarily claiming it is :) ),
the original intention was to only reject on different links from where the
outstanding connection request is.  You are correct in pointing out the
wording doesn't quite say this.  Perhaps we can change it in the upcoming SPL
spec.
I don't remember an intention to ignore the normal fairness rules when OPENs
crossed.
There are a couple of issues with the above scenario:
1) There is nothing defined in SL_CC1:ArbSel to SL_CC2:Selected state
transition (section 7.15.4.3.3) for an STP initiator/target to ignore the
arbitration fairness check;
2) After transmitting the OPEN_REJECT, the target transitions to SL_CC0:Idle
state and would need to resend the OPEN Addr Frame to retry the connection
request. However, if the initiator detects a loss in arbitration and sends an
OPEN_ACCEPT while the target is in SL_CC0:Idle state, the target will miss
the OPEN_ACCEPT. This results in a situation where the target remains in
SL_CC1:ArbSel state (till Open timeout followed by Break timeout occurs) and
the initiator is stuck in SL_CC3:Connected state.
It seems that the description in those paragraphs will make sense if both
connection requests are occurring on different physical links.
Daryl Teo
Intel Corp
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gerry.Houlder at seagate.com  Mon Dec  8 11:20:31 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Mon, 8 Dec 2008 13:20:31 -0600
Subject: Reminder: Dec. 10 telecon on 08-184
Message-ID: <mailman.1005.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
The agenda for the More idle Power options proposal will be:
(1) Cover the power condition model changes for SPL;
(2) Review the Inquiry VPD page changes  from the last telecon;
(3) Review the START STOP UNIT command changes from last telecon;
(4) The rest of the proposal.
Rev. 8 (which includes changes requested at the last telecon) is posted.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-184r8.pdf
Telephone information:
  Toll-free dial-in number: (877)810-9442
Caller paid dial-in number: (636)651-3190
	       Access code: 9367487#
Webex information:
Topic: More Idle power options
Date: Wednesday, December 10, 2008
Time: 10:00 am, Central Standard Time (GMT -06:00, Chicago)
Meeting Number: 822 234 001
Password: partial
-------------------------------------------------------
To join the meeting online
-------------------------------------------------------
1. Go to https://seagate.webex.com/seagate/j.php?ED=103854772&UID=0
2. Enter your name and email address.
3. Enter the meeting password: partial
4. Click "Join".
5. If the meeting includes a teleconference, follow the instructions that
appear on your screen.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Gerry.Houlder at seagate.com  Mon Dec  8 11:28:10 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Mon, 8 Dec 2008 13:28:10 -0600
Subject: Mode page assignment in 08-184
Message-ID: <mailman.1006.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
proposal 08-184 (More Idle Power options) includes a tentative mode page
assignment (0x1A) and a tentative VPD page assignment (0x8A). The SPC
editor asked me to send this email to the reflector to see if anyone else
has a proposal that uses either of these page code assignments. If so,
please reply to the reflector so the SPC editor can resolve the conflict.
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Mon Dec  8 12:58:43 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 8 Dec 2008 13:58:43 -0700
Subject: 08-389r2 - SSC-3: Resolution to LB HPQ-070
Message-ID: <mailman.1007.1441607339.22514.t10@sandbox.t10.org>

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

The proposal to resolve LB HPQ-070 that was approved during the Nov 
meeting week has been uploaded.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-389r2.pdf
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From kdbutt at us.ibm.com  Mon Dec  8 12:56:52 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 8 Dec 2008 13:56:52 -0700
Subject: Minutes: SSC-3 November 04, 2008 Updated
Message-ID: <mailman.1008.1441607339.22514.t10@sandbox.t10.org>

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

Changes shown with change bar
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-437r1.pdf
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From kdbutt at us.ibm.com  Mon Dec  8 13:00:02 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Mon, 8 Dec 2008 14:00:02 -0700
Subject: 08-388r1 - SSC-3: Resolution to LB IBM-027 (PEWZ relation to REW)
Message-ID: <mailman.1009.1441607339.22514.t10@sandbox.t10.org>

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

The proposal to resolve LB IBM-027 that was approved during Nov T10 
meeting has been uploaded.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-388r1.pdf
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From Alvin.Cox at seagate.com  Wed Dec 10 12:20:41 2008
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Wed, 10 Dec 2008 14:20:41 -0600
Subject: Reminder: SAS PHY teleconference, 10:00 am CST, December 11, 2008
Message-ID: <mailman.1010.1441607339.22514.t10@sandbox.t10.org>

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

Agenda:
1. Reflector discussion on cables/connectors
2. External active cables/connectors
3. External and internal > 4x cables/connectors
4. January meeting attendance
5. New items
One teleconference is scheduled for December 11, 2008, 10:00 am CST. 
Additional calls can be arranged if needed.
Toll Free Dial in Number: (877)810-9442 
International Access/Caller Paid Dial-In Number: (636)651-3190 
PARTICIPANT CODE: 3243413 
Webex information: 
https://seagate.webex.com/seagate 
Topic: SAS-2 PHY WG 
Date: Thursday 
Time: 10:00 am, Central Standard Time 
Meeting number: 826 515 680 
Meeting password: 6gbpsSAS 
Alvin Cox
Seagate Technology, LLC
Office 405-392-3738
Cell 405-206-4809


From George.Penokie at lsi.com  Thu Dec 11 09:04:19 2008
From: George.Penokie at lsi.com (Penokie, George)
Date: Thu, 11 Dec 2008 10:04:19 -0700
Subject: Meeting invitation: SAS-2 split editing session
Message-ID: <mailman.1011.1441607339.22514.t10@sandbox.t10.org>

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

I have scheduled an editing meeting to discuss the splitting of SAS-2 into
SAS 2.1 and SPL for 12/18 at 10 AM central time (see below for WebEx and
call-in information).
I have created a preliminary version of a SAS 2.1 that I can make available
to anyone who is interested in participating in this discussion. However, I
do not plan on posting it so if you want it contact me.
Bye for now,
George Penokie
LSI Corporation
3033 41st St. NW
Suite 100
Rochester, MN 55901
507-328-9017
george.penokie at lsi.com
Topic: SAS-2 split editing session
Date: Thursday, December 18, 2008
Time: 10:00 am, Central Standard Time (GMT -06:00, Chicago)
Meeting Number: 570 480 405
Meeting Password: sas2split
Please click the link below to see more information, or to join the meeting.
-------------------------------------------------------
To join the online meeting
-------------------------------------------------------
1. Go to
https://lsilogic.webex.com/lsilogic/j.php?ED=116051097&UID=0&PW=f82c18175f5f0
b1e0f1f4f
2. Enter your name and email address.
3. Enter the meeting password: sas2split
4. Click "Join Now".
-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
Conference Access:
  Toll free:  1-800-531-5745
  Toll:       1-719-955-2349
Passcode:     5073289017
-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://lsilogic.webex.com/lsilogic/mc
2. On the left navigation bar, click "Support".
You can contact me at:
george.penokie at lsi.com
1-507-3289017
To add this meeting to your calendar program (for example Microsoft Outlook),
click this link:
https://lsilogic.webex.com/lsilogic/j.php?ED=116051097&UID=0&ICS=MI&LD=1&RD=2
&ST=1&SHA2=NHR9JGTzxPWMEsm1KstlF3GdJ6Re1oQhDb3fweyIuos=
The playback of UCF (Universal Communications Format) rich media files
requires appropriate players. To view this type of rich media files in the
meeting, please check whether you have the players installed on your computer
by going to https://lsilogic.webex.com/lsilogic/systemdiagnosis.php
Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial
http://www.webex.com
We've got to start meeting like this(TM)
IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and
any documents and other materials exchanged or viewed during the session to
be recorded. By joining this session, you automatically consent to such
recordings. If you do not consent to the recording, do not join the session.


From Alvin.Cox at seagate.com  Fri Dec 12 10:41:07 2008
From: Alvin.Cox at seagate.com (Alvin.Cox at seagate.com)
Date: Fri, 12 Dec 2008 12:41:07 -0600
Subject: PHY WG teleconference minutes posted
Message-ID: <mailman.1012.1441607339.22514.t10@sandbox.t10.org>

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

The minutes of the 12/11 conference call are posted at:
   http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-016r0.pdf
Also note that the new SASWDP code is available for verification at:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-015r0.pdf
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-015r0.zip
Alvin Cox
Seagate Technology, LLC
Office 405-392-3738
Cell 405-206-4809


From kdbutt at us.ibm.com  Fri Dec 12 12:44:02 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 12 Dec 2008 13:44:02 -0700
Subject: SSC-3: Action Items Reminder
Message-ID: <mailman.1013.1441607339.22514.t10@sandbox.t10.org>

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

This is a reminder notice of the SSC-3 Action Items
04Nov08-2 Kevin Butt: Create proposal to resolve Letter Ballot SYM-019 
item a.
04Nov08-5 Working Group: Review Letter Ballot comment IBM-21
04Nov08-7 Working Group: Review IBM-38 to see if it can be accepted. IBM 
and HP say yes
04Nov08-9 Dave to incorporate SSC-3 Resolve LB comments QTM-rbw-103 and 
SYM-022 (08-350r1) into LB comment resolution document and SSC-3
04Nov08-11 Dave Peterson to incorporate SSC-3 Resolve LB comment HPQ-48 
Removable Media Model Clause (08-351r0) as revised into SSC-3 and to 
update the LB comment resolution document.
04Nov08-12 Dave Peterson to contact SMIS guru to discover if any of the 
SMIS commands cause a synchronize to occur. This is to be able to fill out 
the Management Protocol In/Out entries in table 21.
04Nov08-13 Dave Peterson to propose synch and command type for the new 
commands in table 21.
04Nov08-14 Kevin Butt revise SSC-3: Resolution to LB IBM-027 (PEWZ 
relation to REW) (08-388r0) and post.
04Nov08-15 Dave Peterson to mark LB IBM-027 as resolved by SSC-3: 
Resolution to LB IBM-027 (PEWZ relation to REW) (08-388r0) as revised
04Nov08-16 Dave Peterson to incorporate SSC-3: Resolution to LB IBM-027 
(PEWZ relation to REW) (08-388r0) as revised into SSC-3
04Nov08-17 Kevin Butt revise SSC-3: Resolution to LB HPQ-070 (08-389r1) 
and post.
04Nov08-18 Dave Peterson to mark LB IBM-027 as resolved by SSC-3: 
Resolution to LB HPQ-070 (08-389r1) as revised
04Nov08-19 Dave Peterson to incorporate SSC-3: Resolution to LB HPQ-070 
(08-389r1) as revised into SSC-3
04Nov08-20 Dave Peterson to add SSC-3: Clarifying when sense data bits are 
set (08-406r0) as a late letter ballot comment to the Letter Ballot 
comment resolution document.
04Nov08-21 Dale Lafollette to talk to Roger Cummings about SSC-3: 
Resolution to LB Comment EMC-001 (Multiple SDK support) (08-410r0).
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From kdbutt at us.ibm.com  Fri Dec 12 12:50:11 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Fri, 12 Dec 2008 13:50:11 -0700
Subject: SMC-3: Action Items Reminder
Message-ID: <mailman.1014.1441607339.22514.t10@sandbox.t10.org>

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

This is a courtesy reminder of SMC-3 Action Items
06-044 [Roger Cummings] Solicit additional vendor-specific sense codes 
|from library vendors per June discussion item 4.4.
07-017 [Group] Make sure the all the functionality of Read Element Status 
is covered by the Report Element Information command (06-272) and the 
Report Volume Information command and examine if an informative annex to 
map the RES command onto these is appropriate. [Reminder to do as final 
step]
07-042 [Paul Suhler] Write a proposal for the commands which the cached 
ready state in ADC may be used.
14Jan08-09 Curtis Ballard to propose meaning of RANDOM POSITIONING ERROR
14Jan08-11 Kevin Butt to propose meaning of OPERATOR MEDIUM REMOVAL 
REQUEST
14July08-01 Geoff Barton to create a proposal for the use of the NOT READY 
TO READY TRANSITION sense code.
06Aug08-01 Curtis to revise and post 08-201r1 per discussion
20Aug08-05 Kevin to report to Noud what causes the LOGICAL UNIT NOT READY, 
OFFLINE error code to be reported. This needs to be in light of both ADC 
and SMC.
08Sept08-02 Noud Snelder to incorporate SMC-3 Use of INCOMPATIBLE MEDIUM 
INSTALLED (08-270r0) into SMC-3
08Sept08-04 Rod to revise and post SMC-3 Use of LOGICAL UNIT COMMUNICATION 
FAILURE (08-271r0)
03Nov08-01 Kevin Butt to revise SMC-3: Medium Magazine Error Codes 
(07-372r3) and post.
03Nov08-02 Noud Snelder to incorporate SMC-3: Medium Magazine Error Codes 
(07-372r4) into SMC-3.
03Nov08-03 Curtis Ballard to revise SMC-3 Report Volume Information 
(08-215r2) and post.
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com


From Bill.Martin at emulex.com  Fri Dec 12 23:19:21 2008
From: Bill.Martin at emulex.com (Bill.Martin at emulex.com)
Date: Fri, 12 Dec 2008 23:19:21 -0800
Subject: Protocol specific port log page
Message-ID: <mailman.1015.1441607339.22514.t10@sandbox.t10.org>

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

The Protocol-Specific port log page describes a mechanism for reporting phy
events.  The page is broken up into a list of Protocol-Specific Port log
parameter for SAS.  Each of these parameters includes a 1 byte Parameter
Length field. The parameter is made up of a list of SAS phy log descriptors. 
Each of these SAS phy log descriptors contains 52 bytes of fixed information
and  a number of  phy event descriptors, each of which is 12 bytes long. 
There are at least 27 phy event descriptors which could be applicable to a
SAS device, 4 of which are in the first 52 bytes of the SAS phy log
descriptor.  If all 23 remaining event descriptors are implemented, then the
length of the SAS phy log descriptor for one phy would be 52 + 23 * 12 = 328.
 This exceeds the value that it is possible to put into the Parameter Length
field, and does not even account for the possibility of multiple SAS phy log
descriptors for different phys in the port.
What is the intention for a device which supports more descriptors than the
Protocol-Specific Port log parameter for SAS supports?
Bill Martin
Emulex
Office of Technology
Industry Standards
916 772-3658
916 765-6875 (Cell)
bill.martin at emulex.com


From lohmeyer at t10.org  Sat Dec 13 23:00:50 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 14 Dec 2008 00:00:50 -0700
Subject: Recent T10 documents uploaded since 2008/12/07
Message-ID: <mailman.1016.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SBC - Thin Provisioning
(by: Frederick Knight)
T10/08-149r7   Uploaded: 2008/12/08   281001 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-149r7.pdf
SPL Link Layer Power Management
(by: Brian Day)
T10/08-249r4   Uploaded: 2008/12/08   506786 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-249r4.pdf
SBC-3: WRITE SAME unmap bit
(by: David L. Black)
T10/08-356r4   Uploaded: 2008/12/10   56608 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-356r4.pdf
SSC-3: Resolution to LB IBM-027 (PEWZ relation to REW)
(by: Kevin Butt)
T10/08-388r1   Uploaded: 2008/12/08   52155 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-388r1.pdf
SSC-3: Resolution to LB HPQ-070
(by: Kevin Butt)
T10/08-389r2   Uploaded: 2008/12/08   59122 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-389r2.pdf
Minutes: SSC-3 November 04, 2008
(by: Kevin Butt)
T10/08-437r1   Uploaded: 2008/12/08   62832 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-437r1.pdf
SBC-3 Thin Provisioning Threshold Notification
(by: Frederick Knight)
T10/09-011r0   Uploaded: 2008/12/08   48523 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-011r0.pdf
Minutes: CAP - Thin Provisioning 12/4 con-call
(by: Frederick Knight)
T10/09-012r0   Uploaded: 2008/12/08   38063 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-012r0.pdf
Minutes of Dec. 10 More Idle power Options telecon
(by: Gerald Houlder)
T10/09-013r0   Uploaded: 2008/12/10   14670 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-013r0.pdf
SAS-2 SASWDP V1.6
(by: Harvey Newman)
T10/09-015r0   Uploaded: 2008/12/11   23632 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-015r0.pdf
SAS-2 SASWDP V1.6
(by: Harvey Newman)
T10/09-015r0   Uploaded: 2008/12/11   11891 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-015r0.zip
Minutes of SAS PHY Working Group conference call December 11, 2008
(by: Alvin Cox)
T10/09-016r0   Uploaded: 2008/12/12   21804 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-016r0.pdf
Working Drafts
--------------
(Report generated on 2008/12/14 at 00:00:50)
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From billmc37 at ctesc.net  Sun Dec 14 19:37:17 2008
From: billmc37 at ctesc.net (Bill McFerrin)
Date: Sun, 14 Dec 2008 21:37:17 -0600
Subject: [MtFuji] Re: January 2009 MMC WG Meeting Location
Message-ID: <mailman.1017.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Bill McFerrin <billmc37 at ctesc.net>
*
Hi,
I think that something like that may be useful in the future and I hope
that we could consider it. In the short term, we on the schedule in
Orlando. I would like to propose it during that meeting. Everyone is
under pressure to reduce travel costs.
Kind Regards,
Bill McFerrin
David Burg wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * David Burg <daviburg at windows.microsoft.com>
> *
> May I propose a Windows Live Meeting video conference call?
>
> With webcams & microphone we could all stay at our respective offices and
save travel expenses.
>
> With regards,
>
> David.
>
> -----Original Message-----
> From: owner-mtfuji5 at avc-pioneer.com [mailto:owner-mtfuji5 at avc-pioneer.com]
On Behalf Of keiji_katata at post.pioneer.co.jp
> Sent: Thursday, November 13, 2008 5:08 PM
> To: mtfuji5 at avc-pioneer.com
> Cc: T10 Reflector
> Subject: [MtFuji] Re: January 2009 MMC WG Meeting Location
>
>
>
> Dear Bill,
>
> I am same situation with Ai san of Panasonic.
> I cannot attend MMC at Las Vegas because I do not have such budget. Any
cost at
> Las Vegas at the CES time is extremely higher than normal.
>
> Best regards,
>
> Keiji Katata
> PIONEER CORP.
>
>
>
>
>
> Takaharu Ai <ai.takaharu at jp.panasonic.com>@avc-pioneer.com on 2008/11/12
> 17:13:01
>
> mtfuji5 at avc-pioneer.com$B$KJV?.$7$F$/$@$5$$(B
>
> $BAw?.<T(B:     owner-mtfuji5 at avc-pioneer.com
>
>
>
>
>
>
>
> $B08 at h(B:  T10 Reflector <T10 at t10.org>, mtfuji5 at avc-pioneer.com
> cc:
> $B7oL>(B:  Re: [MtFuji] January 2009 MMC WG Meeting Location
>
> Hello Bill,
>
> I prefer the original schedule!
>
> A new project regarding the the slim-line optical disc drive form factor
> were approved by SFF. Although they have not decided yet, they may have
> the SSWG meeting during the T10 week. I expect that many of the ODD
> manufactures who will attend the MMC meeting may also want to attend the
> SSWG. For them, it is better to keep the MMC meeting mapping during the
> T10 week at Orlando.
>
>
> Best Regards,
>
> Harry Ai
> VEBU,
> AVC Networks Company,
> Panasonic Corporation
> Osaka, Japan
>
>
> ---------------- Start of the original message ----------------
>   
>> From: Bill McFerrin <billmc37 at ctesc.net>
>> To: "Mt.Fuji" <mtfuji5 at avc-pioneer.com>, T10 Reflector <T10 at t10.org>
>> Cc:
>> Date: Thu, 06 Nov 2008 14:18:43 -0600
>> Subject: [MtFuji] January 2009 MMC WG Meeting Location
>>
>> MMC WG Members:
>> At this moment, the next MMC WG meeting is planned to be in Orlando, FL
>> USA, Wednesday 14 January 2009. This is likely to be inconvenient for
>> the many people that will be attending CES in Las Vegas during the prior
>> week-end.
>>
>> If it is preferred to arrange a meeting during or near the time of CES,
>> I can arrange a meeting place nearer to Las Vegas. Please notify me as
>> soon as possible, because the T10 meeting sponsor must know our plans by
>> Friday, 14 November.
>>
>> Kind Regards,
>> Bill McFerrin
>>     
>
> ----------------- End of the original message -----------------
>
>
>
>
>
>
>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
>
>   
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Paul.Stone at Quantum.Com  Mon Dec 15 16:15:15 2008
From: Paul.Stone at Quantum.Com (Paul Stone)
Date: Mon, 15 Dec 2008 17:15:15 -0700
Subject: ADC-3 Rev 00e is posted
Message-ID: <mailman.1018.1441607339.22514.t10@sandbox.t10.org>

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

Minor editorial changes only.
http://www.t10.org/cgi-bin/ac.pl?t=f&f=adc3r00e.pdf
Happy holidays everyone.
___________________________________
Paul Stone | Firmware Engineer | Quantum Corporation | Office:
949.725.1874 | paul.stone at quantum.com  
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.


From Paul.Stone at Quantum.Com  Mon Dec 15 17:58:54 2008
From: Paul.Stone at Quantum.Com (Paul Stone)
Date: Mon, 15 Dec 2008 18:58:54 -0700
Subject: ADC-3 Rev 00e is posted
Message-ID: <mailman.1019.1441607339.22514.t10@sandbox.t10.org>

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

Sorry about the confidentiality notice.  Please disregard it.
.......
Minor editorial changes only.
http://www.t10.org/cgi-bin/ac.pl?t=f&f=adc3r00e.pdf
Happy holidays everyone.
___________________________________
Paul Stone | Firmware Engineer | Quantum Corporation | Office:
949.725.1874 | paul.stone at quantum.com  
___________________________________
Disregard the Quantum Corporation confidentiality notice below.  The
information contained in this transmission is not confidential.
Permission is hereby explicitly granted to disclose, copy, and further
distribute to any individual(s) or organization(s), without restriction.
________________________________
The information contained in this transmission may be confidential. Any
disclosure, copying, or further distribution of confidential information
is not permitted unless such privilege is explicitly granted in writing
by Quantum Corporation. Furthermore, Quantum Corporation is not
responsible for the proper and complete transmission of the substance of
this communication or for any delay in its receipt.
________________________________
-----------------------------------------------------------
The information contained in this transmission may be 
confidential. Any disclosure, copying, or further 
distribution of confidential information is not permitted 
unless such privilege is explicitly granted in writing by 
Quantum Corporation. Furthermore, Quantum Corporation is not 
responsible for the proper and complete transmission of the 
substance of this communication or for any delay in its 
receipt.


From Gerry.Houlder at seagate.com  Wed Dec 17 07:46:16 2008
From: Gerry.Houlder at seagate.com (Gerry.Houlder at seagate.com)
Date: Wed, 17 Dec 2008 09:46:16 -0600
Subject: Two new revisions posted
Message-ID: <mailman.1020.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Gerry.Houlder at seagate.com
*
08-015 rev. 6 (Partial and Slumber phy conditions) has been posted.
This revision includes:
(a) code assignments for the four new primitives;
(b) references to 08-420 for enhancements to SMP functions;
(c) Mode page 19h/ subpage 3h is now used to enable power managment in
target devices;
(d) and miscellaneous editorial fixes.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-015r6.pdf
Also 08-184 rev. 9 (More Idle Power Condtions) has been posted.
This revision includes changes requested at the Dec. 10 telecon.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-184r9.pdf
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Dale.Lafollette at Sun.COM  Wed Dec 17 09:15:27 2008
From: Dale.Lafollette at Sun.COM (Dale LaFollette)
Date: Wed, 17 Dec 2008 10:15:27 -0700
Subject: SSC-3: Resolution to LB Comment EMC-001 (Multiple SDK support)
Message-ID: <mailman.1021.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Dale LaFollette <Dale.Lafollette at Sun.COM>
*
I have uploaded  T10/08-410r1 that includes the changes requested at the 
Nov. SSC-3 working group.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-410r1.pdf
Regards,
Dale LaFollette
Principal Engineer, SW, Systems Group
Sun Microsystems, Inc.
500 Eldorado Blvd., Bldg. 5 MS UBRM05-383
Broomfield, CO 80021 United States
Tel: 800-555-9786 ext 77151 / 303-272-7151
Fax: 303-272-6555
Email address: Dale.LaFollette at Sun.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From kdbutt at us.ibm.com  Wed Dec 17 10:39:56 2008
From: kdbutt at us.ibm.com (Kevin D Butt)
Date: Wed, 17 Dec 2008 11:39:56 -0700
Subject: SSC-3: Resolution to LB Comment EMC-001 (Multiple SDK support)
Message-ID: <mailman.1022.1441607339.22514.t10@sandbox.t10.org>

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

Dale,
Here are a few comments on this latest proposal.
1)
Under the Data Encryption Algorithm descriptor:
Table XXX specifies the values for the Decryption KAD Capabilities 
(DKAD_C) field. The DKAD_C field only indicates the decryption 
capabilities associated with DECRYPTION MODE field values of DECRYPT and 
MIXED of the Security Protocol Out command in the Set Data Encryption page 
(see Table 146).
I suggest this rewording to put it into "standardeze".
Table XXX specifies the values for the Decryption KAD Capabilities 
(DKAD_C) field. The DKAD_C field indicates the decryption capabilities 
when theDECRYPTION MODE field of the Set Data Encryption page (see Table 
146) is set to DECRYPT or MIXED.
2)
Under the Data Encryption Algorithm descriptor TABLE XXX DKAD_C field 
values please reword your CHECK CONDITION texts to match this example I 
took from SPC-4 (I think you are just missing the word "status").
shall terminate the command with CHECK CONDITION status, with the sense 
key set to ILLEGAL REQUEST, and the additional sense code set to INVALID 
FIELD IN PARAMETER LIST.
3)
Again in TABLE XXX DKAD_C field values, I would prefer a change in Name 
from:
required -> KAD Required
not required -> KAD Not Allowed
optional -> KAD Optional
4)
Under the Data Encryption Status page your new text reads:
The available supplemental decryption key count (ASDK_COUNT) field 
contains the current number of available supplemental decryption keys that 
the application client may utilize. If the device server is not capable of 
supporting supplemental decryption keys then the ASDK_COUNT field shall 
contain a zero value.
It is not clear to me if this is the number of additional keys that may be 
loaded or if this is the number of keys already loaded.  Please clarify if 
this is the count of keys already loaded or if this is the number of 
additional keys that may be loaded.  Also, please state the relationship 
between this number and the MSDK_COUNTfield of the Data Encryption 
Algorithm descriptor.
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt at us.ibm.com
http://www-03.ibm.com/servers/storage/ 
From:
Dale LaFollette <Dale.Lafollette at Sun.COM>
To:
t10 at t10.org
Date:
12/17/2008 11:08 AM
Subject:
SSC-3: Resolution to LB Comment EMC-001 (Multiple SDK support)
* From the T10 Reflector (t10 at t10.org), posted by:
* Dale LaFollette <Dale.Lafollette at Sun.COM>
*
I have uploaded  T10/08-410r1 that includes the changes requested at the 
Nov. SSC-3 working group.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-410r1.pdf
Regards,
Dale LaFollette
Principal Engineer, SW, Systems Group
Sun Microsystems, Inc.
500 Eldorado Blvd., Bldg. 5 MS UBRM05-383
Broomfield, CO 80021 United States
Tel: 800-555-9786 ext 77151 / 303-272-7151
Fax: 303-272-6555
Email address: Dale.LaFollette at Sun.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From samek at halstor.com  Thu Dec 18 03:46:10 2008
From: samek at halstor.com (Samek)
Date: Thu, 18 Dec 2008 06:46:10 -0500
Subject: SAS-2 rev.15 Missing Sync lost message definition
Message-ID: <mailman.1023.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Samek" <samek at halstor.com>
*
Brian,
Many years of experience taught me, that small probability of the events 
means that they always will happen, and often in the worst possible moments. 
Other protocols send primitives between frames, which facilitate much faster 
recovery from sync loss. More, some of them provide notification to the 
remote transmitter that the receiver is in trouble. SAS doesn't. Instead it 
relays on the ACK timeout from possible hundreds of outstanding frames. This 
means that the recovery is really messy.
Happy Holidays,
Samek
Halstor Inc,
www.halstor.com
----- Original Message ----- 
From: "Day, Brian" <Brian.Day at lsi.com>
To: "Samek" <samek at halstor.com>; "Elliott, Robert (Server Storage)" 
<Elliott at hp.com>; <t10 at t10.org>
Sent: Sunday, December 07, 2008 9:04 PM
Subject: RE: SAS-2 rev.15 Missing Sync lost message definition
>* From the T10 Reflector (t10 at t10.org), posted by:
> * "Day, Brian" <Brian.Day at lsi.com>
> *
> Hello Samek...
>
> I'm not sure I agree with SAS being specified with too infrequent 
> primitives relative to loss of sync.
>
> SAS 2 defines an ALIGN primitive to be sent every 3.4 us (approximately... 
> it is every 128 dwords at 1.5Gbps).
> The DWS Reset Timeout is specified as 1 ms.
>
> So assuming link multiplexxing is not enabled, from the loss of sync 
> (regardless of how often this may occur due a particular system's BER), 
> there are almost 300	ALIGNs permitting a device to recover sync during 
> the DWS Reset Timeout period before it gives up and performs the link 
> reset.
>
>
> Brian Day
> LSI Corporation
>
>
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Samek
> Sent: Saturday, December 06, 2008 11:05 AM
> To: Elliott, Robert (Server Storage); t10 at t10.org
> Subject: Re: SAS-2 rev.15 Missing Sync lost message definition
>
> * From the T10 Reflector (t10 at t10.org), posted by:
> * "Samek" <samek at halstor.com>
> *
> In a real life, due to various factors, the loss of sync will be a common 
> occurence and due to the infriquent primitives may cause link resets, 
> which in SAS/SATA cases are really bad. By the way, dword synchronization 
> may happen any time, not only during a speed negotiations.
>
> Samek Mokryn
> President
> HalStor Inc.
> www.halstor.com
>
> ----- Original Message -----
> From: "Elliott, Robert (Server Storage)" <Elliott at hp.com>
> To: <t10 at t10.org>
> Sent: Wednesday, December 03, 2008 2:30 PM
> Subject: RE: SAS-2 rev.15 Missing Sync lost message definition
>
>
>>* From the T10 Reflector (t10 at t10.org), posted by:
>> * "Elliott, Robert (Server Storage)" <Elliott at hp.com>
>> *
>> DWS Lost is the name of a message going to SP, not the SP receiver.
>> They're sent at similar times and possibly could be made identical.
>>
>> Although the SAS standard (like most other serial protocols) only
>> requires a BER of 10^12 (which is one error every 2.77 min per one
>> direction of a physical link at 6 Gbps), a system generating anywhere
>> near those number of errors will have so many other problems it won't
>> be viable.  Dword synchronization mainly just happens once during
>> speed negotiation. Most of the time is spent finding the center of the
>> bits; once done, identifying the dword boundary by finding a comma is 
>> easy.
>>
>>
>>
>> -----Original Message-----
>> From: Samek [mailto:samek at halstor.com]
>> Sent: Tuesday, December 02, 2008 6:13 PM
>> To: Elliott, Robert (Server Storage); t10 at t10.org
>> Subject: Re: SAS-2 rev.15 Missing Sync lost message definition
>>
>> It looks to me that the DWS Lost message does the same job. I can
>> hardly see why there is a need for two.
>> These are however minor problems. I have much bigger problem with the
>> fact that the comma characters are so sparse in the SAS protocol,
>> resulting in a longer time to acquire synchronization, specially in
>> the noisy environment (please note that with a lower bit energy in
>> faster rates the SNR drops dramatically), which may lead to link
>> resets - catastrophic from the performance point of view.
>>
>> Samek Mokryn
>> President
>> HalStor Inc.
>> www.halstor.com
>>
>>
>>
>> ----- Original Message -----
>> From: "Elliott, Robert (Server Storage)" <Elliott at hp.com>
>> To: <t10 at t10.org>
>> Sent: Tuesday, December 02, 2008 11:17 AM
>> Subject: RE: SAS-2 rev.15 Missing Sync lost message definition
>>
>>
>>>* From the T10 Reflector (t10 at t10.org), posted by:
>>> * "Elliott, Robert (Server Storage)" <Elliott at hp.com>
>>> *
>>> The SP receiver detects ALIGNs, TRAIN_DONEs, and Dwords and sends
>>>them as  ALIGN Received, TRAIN_DONE Received, and Dword Received
>>>messages.  See  figure 35 on page 72.
>>>
>>> If dword synchronization has been lost, however, it stops sending
>>> those messages.  SP_DWS tells the SP receiver that dword
>>> synchronization has been lost using the Sync Lost message.	See this 
>>> wording on page 285:
>>>
>>> "The ALIGN Received, Dword Received, and TRAIN_DONE Received messages
>>> are only sent after the SP_DWS state machine has achieved dword
>>> synchronization."
>>>
>>> ________________________________
>>>
>>> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Samek
>>> Sent: Thursday, November 27, 2008 1:46 PM
>>> To: t10 at t10.org
>>> Subject: SAS-2 rev.15 Missing Sync lost message definition
>>>
>>>
>>> SP_DWS (6.9) defines a Sync Lost message sent by the SP_DWS state
>>> machine to the SP receiver, however there is no definition anywhere
>>> what the SP receiver should do with this message. Any suggestions?
>>>
>>> Happy Thanksgiving
>>>
>>> Samek Mokryn
>>> President
>>> Halstor Inc.
>>> www.halstor.com
>>>
>>> *
>>> * For T10 Reflector information, send a message with
>>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>>
>>
>>
>> *
>> * For T10 Reflector information, send a message with
>> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>>
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
>
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From roweber at IEEE.org  Thu Dec 18 06:26:30 2008
From: roweber at IEEE.org (Ralph Weber)
Date: Thu, 18 Dec 2008 08:26:30 -0600
Subject: Completed OSD-2 LB Resolutions makes PUNCH command optional
Message-ID: <mailman.1024.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Ralph Weber <roweber at ieee.org>
*
The latest version of the OSD-2 Letter Ballot Comments
Resolution is ready for CAP/T10 consideration and forwarding
to first public review in Orlando.
The big, last-minute change is comment Other-36 which makes
the PUNCH command optional. Complaints were raised that the
PUNCH function unfairly constrains the possible on-disk formats
an OSD might use. Making the command optional seemed like the
simplest way to return vendor neutrality to the standard.
The applicable documents are:
Main comments resolutions:
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-380r4.pdf
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-380r4.fdf
Supplemental comments resolutions (for complicated changes):
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-395r3.pdf
Edited working draft:
http://www.t10.org/cgi-bin/ac.pl?t=f&f=osd2r04d.pdf
For suggestions on how to view these documents optimally,
please see the first few pages of 08-380r4.pdf.
All the best,
.Ralph
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From mikeb at bustrace.com  Thu Dec 18 06:33:19 2008
From: mikeb at bustrace.com (Mike Berhan)
Date: Thu, 18 Dec 2008 06:33:19 -0800
Subject: SPC-4 Protocol Specific Logical Unit mode page
Message-ID: <mailman.1025.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Mike Berhan" <mikeb at bustrace.com>
*
Advanced apologies if this has already been pointed out.
Page 444, Table 359, SPC-4 r17.  This table defines the Protocol Specific
Logical Unit mode page.  Offset 2, bits 7-4 are reserved.  Offset 3+ are the
protocol specific mode parameters.
Page 561, Table 221, SAS-2 r15 (same applies to SAS-1).  This table details
the SAS version of this mode page.  Note, however, that SAS defines bit 4
offset 2 as the "Transport Layer Retries" bit.
Reserved is well defined as:
3.3.8 reserved: A keyword referring to bits, bytes, words, fields and code
values that are set aside for future
standardization. A reserved bit, byte, word or field shall be set to zero,
or in accordance with a future extension to
this standard. Recipients are not required to check reserved bits, bytes,
words or fields for zero values. Receipt of
reserved code values in defined fields shall be reported as an error.
The SAS specification conflicts with the SPC specification in this regard.
I believe SPC-4 should be amended to clarify this conflict.  Perhaps define
that one bit, or all four bits, as protocol specific as opposed to reserved.
Regards,
-------
Mike Berhan
busTRACE Technologies
9700 Village Center Drive
Suite 50-F
Granite Bay, CA  95746
916.773.4554 phone
916.218.6283 fax
http://www.bustrace.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From Dale.Lafollette at Sun.COM  Thu Dec 18 15:52:20 2008
From: Dale.Lafollette at Sun.COM (Dale LaFollette)
Date: Thu, 18 Dec 2008 16:52:20 -0700
Subject: SSC-3 Resolution to LB Comment EMC-001 (Multiple SDK support)
Message-ID: <mailman.1026.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* Dale LaFollette <Dale.Lafollette at Sun.COM>
*
I have uploaded T10/08-410r2 that includes review comments from r1.
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-410r2.pdf
Regards,
Dale LaFollette
Principal Engineer, SW, Systems Group
Sun Microsystems, Inc.
500 Eldorado Blvd., Bldg. 5 MS UBRM05-383
Broomfield, CO 80021 United States
Tel: 800-555-9786 ext 77151 / 303-272-7151
Fax: 303-272-6555
Email address: Dale.LaFollette at Sun.com
*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org


From scott.shuey at tycoelectronics.com  Fri Dec 19 10:33:33 2008
From: scott.shuey at tycoelectronics.com (Shuey, Scott)
Date: Fri, 19 Dec 2008 13:33:33 -0500
Subject: Tyco Proposal 09-014r0.pdf posted 10-18-2008
Message-ID: <mailman.1027.1441607339.22514.t10@sandbox.t10.org>

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

http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-014r0.pdf
Scott A. Shuey
Standards Engineer
Communications, Computer & Consumer Electronics Group
3101 Fulling Mill Rd.
Middletown, Pa 17057
Mail stop 128-51
phone: 717-592-3371
cell: 717-215-6808
e-mail: scott.shuey at tycoelectronics.com
This email transmission (and any of its attachments) may contain
confidential, proprietary and/or privileged information.  The sender intends
this transmission only for the designated recipient(s).  If you are not a
designated recipient (or authorized to receive for a designated recipient),
you are hereby notified that the disclosure, copying, distribution or use of
any of the information contained in this transmission is strictly prohibited.
 If you have received this transmission in error, please destroy this
message, delete any copies which may exist on your system and notify the
sender immediately.  Thank you.


From curtis.ballard at hp.com  Fri Dec 19 10:45:43 2008
From: curtis.ballard at hp.com (Ballard, Curtis C (StorageWorks))
Date: Fri, 19 Dec 2008 18:45:43 +0000
Subject: SMC-3 Working Group conference call 7 January, 8:00 AM PST
Message-ID: <mailman.1028.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* "Ballard, Curtis C (StorageWorks)" <curtis.ballard at hp.com>
*
Hewlett Packard will host a teleconference for the SMC-3 working group on
Wednesday, 7 January.  Contact details for that meeting follow this message. 
Please contact me for access numbers from any countries not listed.
The agenda will be posted to T10 before the meeting.
Curtis Ballard
Hewlett Packard
-----------------------------------------
Conference Call Passcode:	8983013
Conference Call Access Numbers:
U.S. (toll) dial-in number	281.964.1607
U.S. toll-free dial-in number	877.675.4345
Germany 			069-22-221-6176 or 800-664-7543
Netherlands - Amsterdam 	020-714-3562 or 0800-023-5079
Norway - Oslo			21-033-192 or 800-18-430
United Kingdom			0844-579-0686 or 0808-238-0672
Virtual Rooms Link:
https://www.rooms.hp.com/attend/default.aspx?key=EHF6UG27GV
*
* 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 Dec 20 23:00:50 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 21 Dec 2008 00:00:50 -0700
Subject: Recent T10 documents uploaded since 2008/12/14
Message-ID: <mailman.1029.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SAS: Add low power transceiver options
(by: Gerald Houlder)
T10/08-015r6   Uploaded: 2008/12/16   103391 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-015r6.pdf
SPC-4 SBC-3 SPL Adding more idle power options
(by: Gerald Houlder)
T10/08-184r9   Uploaded: 2008/12/16   235608 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-184r9.pdf
MtFuji7 revision 1.11 Draft
(by: William McFerrin)
T10/08-237r1   Uploaded: 2008/12/15   8758710 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-237r1.pdf
Response to T10 Letter Ballot comments on OSD-2
(by: Ralph O. Weber)
T10/08-380r4   Uploaded: 2008/12/17   563891 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-380r4.fdf
Response to T10 Letter Ballot comments on OSD-2
(by: Ralph O. Weber)
T10/08-380r4   Uploaded: 2008/12/17   658945 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-380r4.pdf
Supplemental changes for OSD-2 Letter Ballot comments
(by: Ralph O. Weber)
T10/08-395r3   Uploaded: 2008/12/17   154716 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-395r3.pdf
ADT-2:	Internet ADT (iADT)
(by: Paul Suhler)
T10/08-409r4   Uploaded: 2008/12/19   476652 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-409r4.pdf
SSC-3: Resolution to LB Comment EMC-001 (Multiple SDK support)
(by: Dale LaFollette)
T10/08-410r1   Uploaded: 2008/12/17   98802 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-410r1.pdf
SSC-3: Resolution to LB Comment EMC-001 (Multiple SDK support)
(by: Dale LaFollette)
T10/08-410r2   Uploaded: 2008/12/18   99832 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-410r2.pdf
Tyco Electronics External 8x Mini SAS w/ 4x Modular Capability
(by: Scott Shuey)
T10/09-014r0   Uploaded: 2008/12/18   1043927 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-014r0.pdf
SAM5 - QUERY TASK TMF Progress Indicator
(by: Frederick Knight)
T10/09-017r0   Uploaded: 2008/12/18   22879 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-017r0.pdf
SPC-4 / SBC-3 - Timeout notification enhancements
(by: Frederick Knight)
T10/09-018r0   Uploaded: 2008/12/18   130943 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-018r0.pdf
SPC-4 - Reclaim some Obsolete bits for future use
(by: Frederick Knight)
T10/09-019r0   Uploaded: 2008/12/18   58989 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-019r0.pdf
T11 Liaison Report, December 2008
(by: Robert Snively)
T10/09-020r0   Uploaded: 2008/12/19   13117 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-020r0.pdf
Working Drafts
--------------
Automation/Drive Interface Commands - 3 (ADC-3)
(Editor: Paul Stone)
 Rev: 00e      Uploaded: 2008/12/15   1070315 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=adc3r00e.pdf
Object-Based Storage Devices - 2 (OSD-2)
(Editor: Ralph Weber)
 Rev: 04d      Uploaded: 2008/12/17   0 bytes
http://www.t10.org/cgi-bin/ac.pl?t=f&f=osd2r04d.pdf
(Report generated on 2008/12/21 at 00:00:50)
*
* 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 Dec 27 23:00:51 2008
From: lohmeyer at t10.org (T10 Document Administrator)
Date: Sun, 28 Dec 2008 00:00:51 -0700
Subject: Recent T10 documents uploaded since 2008/12/21
Message-ID: <mailman.1030.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 Document Administrator <lohmeyer at t10.org>
*
Proposals
---------
SPL Link Layer Power Management
(by: Brian Day)
T10/08-249r5   Uploaded: 2008/12/22   507661 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-249r5.pdf
SPL: Power Management Reporting and Control
(by: Brad Besmer)
T10/08-420r1   Uploaded: 2008/12/26   77113 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-420r1.pdf
Optical SAS Architecture
(by: Kevin Witt)
T10/09-021r0   Uploaded: 2008/12/22   769677 bytes
http://www.t10.org/cgi-bin/ac.pl?t=d&f=09-021r0.pdf
Working Drafts
--------------
(Report generated on 2008/12/28 at 00:00:51)
*
* 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  Sun Dec 28 01:00:00 2008
From: lohmeyer at t10.org (T10 List Manager)
Date: Sun, 28 Dec 2008 02:00:00 -0700
Subject: T10 Reflector Monthly Reminder
Message-ID: <mailman.1031.1441607339.22514.t10@sandbox.t10.org>

* From the T10 Reflector (t10 at t10.org), posted by:
* T10 List Manager <lohmeyer at t10.org>
*
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