This message is from the T13 list server.

Even with PATA SRST does not always shake a drive into a controlled
condition (although very rarely). We have found that HRSET is more reliable.
With SATA we can issue a COMRESET but have seen drives that do not respond
correctly and only a power cycle will get them back on track. The symptom is
similar to that described, the drive never comes back with the initial
register FIS. Without a physical reset line there is always a reliance on
some elements of the device working to complete a reset request. Something
we have to live with!



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 02, 2003 2:52 PM
To: [EMAIL PROTECTED]
Subject: RE: [t13] SRST behavior on SATA


This message is from the T13 list server.


|---------+---------------------------->
|         |           "Grimsrud, Knut  |
|         |           S"               |
|         |           <knut.s.grimsrud@|
|         |           intel.com>       |
|         |           No Phone Info    |
|         |           Available        |
|         |                            |
|         |           10/02/2003 03:00 |
|         |           PM               |
|         |                            |
|---------+---------------------------->
 
>---------------------------------------------------------------------------
---------------------------------------------------|
  |
|
  |       To:       <[EMAIL PROTECTED]>,
<[EMAIL PROTECTED]>
|
  |       cc:       <[EMAIL PROTECTED]>
|
  |       Subject:  RE: [t13] SRST behavior on SATA
|
 
>---------------------------------------------------------------------------
---------------------------------------------------|




Tony's comments are correct. However, the bottom line is that if SRST is
reliably delivered to the drive, then the drive should reliably perform
a SRST. If it does not, then something is amiss.

                         Knut


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]

Sent: Thursday, October 02, 2003 1:54 PM
To: [EMAIL PROTECTED]
Cc: Grimsrud, Knut S; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [t13] SRST behavior on SATA


The soft reset requires two FIS27s.  One to set SRST, and some time
later,
one to clear it.. The drive should respond some time after the second
FIS
to clear SRST with a  FIS34.   BSY should be set when SRST is set and
not
cleared until the device responds with its status FIS.

If he is seeing conditions where the two FISes are being sent to the
drive,
and a status is not being sent back to the host with our drive I'd like
to
hear more.

His observation that a COMRESET may be more reliable is true and may be
even comprehended in some future HBA specifications.  SRST is steeped in
some history.  First is that most host controllers never provided a
means
to expose HRST.  Second, in SATA is a point-to-point bus, so COMRESET
(hard
reset) only affects one device anyway, and it is becoming more obvious
that
a COMREEST now has to be  a backup to the SRST anyway, so just as well
use
the one that is guaranteed.  You might still have to re-establish some
parameters that are cleared on a hard reset that aren't reset by a SRST
but
if you already have to be prepared to both kinds of reset I can't see
you
save anything by having a hierarchical reset strategy.

Thanks,
Tony



|---------+---------------------------->
|         |           James C Hatfield |
|         |           720-684-2120     |
|         |                            |
|         |           10/02/2003 14:14 |
|         |                            |
|---------+---------------------------->

>-----------------------------------------------------------------------
-----------------------------------------------------------------------|
  |
|
  |       To:       Tony L Priborsky/Seagate, [EMAIL PROTECTED],
Robert W Dixon/Seagate
|
  |       cc:
|
  |       Subject:  [t13] SRST behavior on SATA
|

>-----------------------------------------------------------------------
-----------------------------------------------------------------------|



Comments, please ?

Thank You !!!
-----------------------------------------------------------------
Jim Hatfield
ATA Interface Firmware & T13 (ATA/ATAPI) Standards Representative
Seagate Technology - PSG
   e-mail:  [EMAIL PROTECTED]
   s-mail:  389 Disc Drive;  Longmont, CO 80503 USA
   voice:   720-684-2120
   fax    :    720-684-2711
====================================================
----- Forwarded by James C Hatfield/Seagate on 10/02/2003 02:13 PM -----
|---------+---------------------------->
|         |           Mark Overby      |
|         |           <[EMAIL PROTECTED]|
|         |           om>              |
|         |           Sent by:         |
|         |           [EMAIL PROTECTED]|
|         |           rg               |
|         |           No Phone Info    |
|         |           Available        |
|         |                            |
|         |           10/02/2003 01:40 |
|         |           PM               |
|         |                            |
|---------+---------------------------->

>-----------------------------------------------------------------------
-----------------------------------------------------------------------|
  |
|
  |       To:       "'ATA T13 Reflector'" <[EMAIL PROTECTED]>
|
  |       cc:
|
  |       Subject:  [t13] SRST behavior on SATA
|

>-----------------------------------------------------------------------
-----------------------------------------------------------------------|




I see host controllers execute the correct method of issuing SRST to the
drive (FIS 27 with C=0, Control = 4). According to the DSR1:DSR2 or
DSR1:DSR3 state machines, the drive should be sending back a successful
(or
failure) register FIS back to the controller. However, I'm noticing that
drives do not seem to send that back and in addition, the specification
does not specify a timeout value for how long this operation can take.
(ATA-7 Vol 2 specifies that device 0 should terminate the operation and
set
an error bit if PDIAG- is not asserted in <= 31 s).

Seems like a potential race problem here if the HC leaves BSY up while
it's
waiting for the drive to send back a register FIS indicating the status
completion of the SRST.

Obviously, the HC (and possibly upper level software) has the ultimate
hammer of doing a COMRESET on the bus to bring the drive back into a
known
state.

Am I missing anything? Comments?








Reply via email to