RE: [t13] SATA Async loss vs HRESET... settings of the drive

[Wolford, Jeff]

Title: Message

Gary,   Let me try and answer both yours and a couple Hale's questions at the same time (watch out) For background and clarification purposes, since some of us are a little out of the loop these days.  What condition(s) could lead to Async loss of signal?  Is this a catastrophic condition (i.e. unlikely but possible) or just an occasional emotional issue (hiccup) on the interface? This could aid in the suggestion of possible solutions. [JWW> ] An Async loss of signal can happen with ANY minor glitch in the phy signal since SATA is an always ON interface (unless you go into a low/lower phy power state).   It is VERY catastrophic, as Hale indicated there are a LARGE number of conditions where a SRST will not reset the bus and causing a COMRESET is SATA specific and I don't know of any SATA aware OSs yet... (I'm still waiting for the Linux kernel to support native mode PATA controllers)   And since there is no STANDARD way to cause a COMRESET, each of the OSs is going to have to know about every controller.   The BAD part is a Async loss of signal (in the best case if it does not LOCK up the SATA bus), it resets a lot of the drive parameters and the OS has virtually no way to know it happened.   The 2nd BAD part is this is NOT like PATA... where SRST always got you out of a hung condition and the OS did NOT have to reprogram the drive (it was just a SRST not a HRESET).   How often: I see them every 2 or 3 days, but they are localized (i.e. they are drive/system combination dependent) and NEVER -:) on a system with a bus analyzer on them with the right trigger (tracing the low level will fill up the buffer real quick -:)   Jeff   Gary Laatsch [EMAIL PROTECTED] ----- Original Message ----- From: Wolford, Jeff To: ATA T13 Reflector Sent: Saturday, September 20, 2003 10:26 AM Subject: [t13] SATA Async loss vs HRESET... settings of the drive And now for a tough one to solve...   SUMMARY:     What happens to the soft settings of a drive during a Async loss of signal ?      (such as UDMA mode, IDP values, Multi settings or any other setfeat soft setting)   SUGGESTION: Drives need to know the difference between a Async loss of signal and a commanded COMRESET. If it is a Async loss of signal, they need to maintain the "soft settings", if its a commanded COMRESET, they need to reset all the settings and expect the OS to reprogram them   BACKGROUND: On SATA Comreset is equated to HRESET on PATA.  Also Async loss of signal on SATA is equated to COMRESET.... HOWEVER, there is a problem (ok only one -:) with this assumption.   On PATA HRESET happens VERY view times (at boot, commanded reboot and coming out of S3 and S4).  Each of these times the OS / BIOS is VERY aware that this is happening.   HOWEVER, on SATA Async loss of signal is NOT commanded and the OS is NOT very aware and has NO was of knowing if it is not VERY SATA aware (aka the OS would have to poll the SATA SERROR / SSTATUS non-standard location registers).   Thus the OS does not know to comedown and reprogram the drive with the right UDMA mode, multi setting for read multiple, IDP values, etc).   CURRENT SITUATION:   Several SATA drives on the market today will totally lock up and a SRST will NOT get them out of this condition.   Example 1:  On a Async loss of signal, Several drives will reset the PATA portion (thus loose the soft setting of DMA mode and revert back to multiword DMA), the SATA to PATA conversion portion is fixed in UDMA mode...  BINGO... LOCK up   Example 2: BIOS / OS setup a multi setting of 16 for a read / write multiple.  Then a ASYNC loss of signal, multi reverts back to 1 or something other than 16 on the drive.  OS does a write multi... BINGO Lock up   .... And the list goes on.   All soft settings need to be addressed.   Jeff   Jeff Wolford                       Email: [EMAIL PROTECTED] Senior Architect Storage Interface and Tools -  Business PC Products  Group     Voice: (281) 514-9465,     Pager: (800) 973-5739 Hewlett-Packard Corporation