This message is from the T13 list server.

Where in the universe has Spocks brain gone??

I am not certain about SATA behavior, but in PATA, when the DF bit is set,
the BSY but needs to be cleared in order to let the host read the condition.
When the DF bit is set, if the command register is stored, the BSY bit is
not cleared, the DF bit remains one, and the command is not executed.  This
condition informs the host that something catastrophic has happened and that
some physical action needs to be taken.  Simply resetting the drive will not
clear the error.  I do not believe that this is a freeze condition...
Common conditions that cause a 20h status are failure to spin-up and spare
pool empty.

I also believe that if somebody is advocating setting BSY to one and going
off-line as a solution, they will find that the host may totally
misunderstand the problem.  Going off-line in that manner could mean
anything.  When the device returns a 20h or 21h status, the device has
indicated that the registers are valid to read, it is not ready, and it has
a fault.  The device prevents new commands from being issued by the host
when it leaves RDY cleared.

 
-------------------------------------------------
Curtis E. Stevens
20511 Lake Forest Drive #C-214D
Lake Forest, California 92630
Phone: 949-672-7933
Cell: 949-307-5050
E-Mail: [EMAIL PROTECTED]
Question: If you could live forever, would you and why?  Answer: "I would
not live forever, because we should not live forever, because if we were
supposed to live forever, then we would live forever, but we cannot live
forever, which is why I would not live forever," --Miss Alabama in the 1994
Miss USA contest
 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Larry
Barras
Sent: Tuesday, March 08, 2005 4:26 PM
To: Mark Overby; Harlan Andrews; John Masiewicz
Cc: [email protected]
Subject: RE: [t13] Inquiries into SATA material during ATA/8 review

This message is from the T13 list server.


Unless of course, the thing on the other end is broke.

That's why it should abort the command, then never clear busy 
following any reset.

He's dead Jim!



At 3:05 PM -0800 3/8/05, Mark Overby wrote:
>This message is from the T13 list server.
>
>
>The problem with that is how do you differentiate between an interface
>problem and a problem with a cached write? Sounds like what you're
>really asking for is DF behavior or a new error bit behavior.
>
>As a host I can't tell the difference. If the BSY bit is stuck on, I'm
>going to expect to be able to clear that with either a SRST, hard reset,
>or COMRESET (depending on the interface)
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>Larry Barras
>Sent: Tuesday, March 08, 2005 2:18 PM
>To: Harlan Andrews; John Masiewicz
>Cc: [email protected]
>Subject: Re: [t13] Inquiries into SATA material during ATA/8 review
>
>This message is from the T13 list server.
>
>
>There is a subtle difference between "freeze" and abort in this case.
>
>What the drive should actually do in this case is abort the command
>and stick busy.
>
>Freeze would mean literally "do nothing".
>
>I brought up the same point at the discussion, but I see what they
>are getting at with the term freeze meaning "do nothing". What we
>want in this case is the drive to abort and stay BSY=1 until power
>cycled as a signal that things have gone very wrong.
>
>
>
>At 2:06 PM -0800 3/8/05, Harlan Andrews wrote:
>>John,
>>
>>One case where drives currently "Freeze" is when a cashed write
>>fails.    At that point, the host must be notified that one or more
>>of the previously successfully acknowledged writes was unable to be
>>written.    The current behavior of several drives is to freeze
>>until a power cycle occurs.   NOTE:   a COMRESET does NOT ( and
>>should not) reset this condition.  Only the power cycle resets this
>>condition.
>>
>>I would MUCH rather see a more identifiable error condition.
>>Ideally, the drive should return a specific error to ALL commands
>>until it is explicitly reset by the host.    The "reset" should NOT
>>be any currently defined command.   It should be explicitly reserved
>>to reset the failed cashed write.   The host must not be allowed to
>>continue without specifically acknowledging that data on the drive
>>HAS BEEN CORRUPTED.
>>
>>...Harlan
>>
>>
>>On Mar 8, 2005, at 1:44 PM, John Masiewicz wrote:
>>
>>>Brian,
>>>
>>>I don't think you asked quite the right questions as posed in the
>>>meeting, especially regarding the BIST.
>>>
>>>BIST was not listed are re-transmittable in the list, but if you
>>>look at the Device Transport BIST Activate state diagram, a retry
>>>is explicitly directed. This was the inconsistency we were trying
>>>correct. I don't have any problem adding a note, but the two
>>>section are not in agreement, thus the request for clarification,
>>>it there is any.
>>>
>>>
>>>
>>>The issue with "Freeze" is that it is recommended. I cannot think
>>>of any condition where I would recommend a drive "Freeze" as a
>>>policy. (I have no objection to hosts freezing) Freeze means rely
>>>on timeouts, which in ATA are as long as 30 seconds. This does not
>>>sound like a good recommendation for error handling if you know you
>>>are in an unrecoverable situation.  Freeze, as discussed in the
>>>meeting, implies do nothing, and respond to nothing (except
>>>COMRESET).  If a device is so perturbed that it unrecoverable and
>>>it knows this, certainly a COMINIT  from the device or COMRESET
>>>from the host might be recommended, but not "freezing".
>>>
>>>
>>>
>>>I prefer eliminating the unnecessary recommendation, since it
>>>offers nothing in terms of error recovery, but rather says do not
>>>perform error recovery. Similarly, it is in a section entitled
>>>"Software error recovery" and I would not recommend that the
>>>software "freeze".
>>>
>>>
>>>
>>>Please, however, review the state machines on the BIST retry, and
>  >>reconsider your recommendation.
>>>
>>>
>>>
>>>John Masiewicz
>>>
>>>Western Digital
>>>
>>>
>>>
>>>
>>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>>>Dees, Brian M
>>>Sent: Tuesday, March 08, 2005 8:44 AM
>>>To: [email protected]
>>>Subject: [t13] Inquiries into SATA material during ATA/8 review
>>>
>>>
>>>
>>>Hi,
>>>           During the review of the ATA/8 Serial Transport material
>>>in the February T13 Summit a few items were given to me as the
>>>liaison into the SATA-IO to research the meaning or intent.  Below
>>>are the questions and responses I've recorded in finding the
>>>details.
>>>
>>>1. What was the original intent of listing 'Freeze' as a valid
>>>category for error responses? (see sections 10.1 & 10.5.2 of
>>>d1697r0a-ATA8-ST, where Freeze has been removed)
>>>
>>><Original reference in sections 11.1 (pg 273) and 11.5.2 (pg 279)
>>>of Serial ATA 1.0a.>
>>>Freeze is the condition the drive enters where a host action like a
>>>reset is required to recover the drive. Whether you admit it or
>>>not, it is not unusual for drives to enter this state. Serial ATA
>>>might have been the first to explicitly call this behavior out,
>>>although it is not an unusual occurrence. In hopelessly messed up
>>>situations, it is probably safer for a drive to halt and await the
>>>host cleaning up with a reset than it might be for the drive to
>>>proceed and potentially exacerbate the situation.
>>>
>>>2. Why isn't BIST Activate included in the list of frame types that
>>>can be retransmitted? (see section 10.4.3.2 of d1697r0a-ATA8-ST)
>>>
>>><Original reference in section 11.4.2.2 (page 278) of Serial ATA
>1.0a.>
>>>BIST is not a function performed during the normal course of
>>>operation for a disk drive. Since it's an engineering lab-bench
>>>function to be used in controlled conditions by knowledgeable
>>>experts, it does not have the kinds of automatic recovery that
>>>normal user functions might have. In some lab settings, it could
>>>even be detrimental for auto-recovery operations to be performed by
>>>the interface, since some lab functions are for the purpose of
>>>examining such behaviors. If the BIST Activate function fails in a
>>>lab setting, the engineer is presumably sufficiently capable to
>>>know what is happening and attempt the operation over again.
>>>
>>>          With the understanding of the above explanations, I believe
>>>that 'Freeze' should be re-inserted back into the ATA/8 material
>>>and that BIST Activate should still not exist in the list referred
>>>to by question #2.  This would require three total edits, although
>>>minor, into the next revision of the document.
>>>
>>>Regards,
>>>Brian
>
>
>--
>
>---------------------
>I make stuff go.
>---------------------
>
>Larry Barras
>Apple Computer Inc.
>1 Infinite Loop
>MS:  306-2TC
>Cupertino, CA  95014
>(408) 974-3220


-- 

---------------------
I make stuff go.
---------------------

Larry Barras
Apple Computer Inc.
1 Infinite Loop
MS:  306-2TC
Cupertino, CA  95014
(408) 974-3220


Reply via email to