In many hundreds of hours of testing on a significant number of systems, I've not hit an instance of async signal loss on the SATA bus that was not due to some issue in the physical connection. (ie, bad cable)
Many of the current shipping drives are built around a sata-ata bridge device, which is integrated on the drive's logic card.
The drive vendor is responsible for making the drive as a whole act like a SATA drive at the terminals. Since they know they are integrating the devices, they certainly should have no problem setting up the pATA parts of the drive to always and forever be at the correct transfer modes given whatever bridge they choose to employ internally to their architecture. The OS should not have to issue any set transfer mode commands to a SATA drive, and any sent should be ignored at the drive.
While the whole notion of SATA is to fool the OS into thinking that is still connected to plain-old vanilla ATA disk, it just doesn't come out in the wash. There's really no way to completely ignore the SATA controller in the driver layer and do it right with a generic ATA disk driver. Nor is there a way to properly drive any ATA controller in a completely generic manner either for that matter.
The whole premise of transparency is more or less a farce. It's more like 90% translucent.
At 8:48 PM -0500 9/21/03, Wolford, Jeff wrote:
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 <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]
----- Original Message ----- From: <mailto:[EMAIL PROTECTED]>Wolford, Jeff To: <mailto:[EMAIL PROTECTED]>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
--
--------------------- I make stuff go. ---------------------
Larry Barras Apple Computer Inc. 1 Infinite Loop MS: 306-2TC Cupertino, CA 95014 (408) 974-3220
