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
----- Original Message -----
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...
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)
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
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,
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
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
