This message is from the T13 list server.
Why not just set the ABRT bit and set DF? -----Original Message----- From: Larry Barras [mailto:[EMAIL PROTECTED] 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 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
