This message is from the T13 list server.

This may seem redundant to some of you but Pat Lavarre (and others)
have talked some about conditions when commands complete abnormally.
There seem to be several reasons for this:

* Device power is unreliable. Device resets in the middle of a
command. BAD HOST.

* Device thinks it has seen RESET- asserted. BAD HOST or BAD DEVICE
or BAD CABLE.

* Device timeouts the host and just "resets". VERY BAD DEVICE.

And Pat has talked several times about various X-to-ATA/ATAPI bridge
things. In this case I want to make sure that everyone understands
that in the ATA/ATAPI world the thing on the other side of the cable
from the ATA/ATAPI device(s) is the ATA/ATAPI host. Please note that
the X in X-to-ATA/ATAPI is NOT the ATA host. The bridge thing is the
ATA/ATAPI host. An ATA/ATAPI host is expected to follow the ATA/ATAPI
protocols and have a design that is compatible with the ATA/ATAPI
standards. I know from experience that some of these bridge things
are not very good ATA/ATAPI hosts and they are extremely unreliable
ATA/ATAPI hosts. They only work if the actual host places only a very
lite workload upon them using the most simple command executions
sequences.

But in any case the ATA/ATAPI interface should not be expected to
work unless both sides of the cable, device AND host, are implemented
somewhat correctly. This means, for example, that a bridge thing
should be able to detect when a command has executed correctly and
when a command has transferred the correct number of data bytes, etc,
... all the same things an true ATA/ATAPI host usually can do with
little problem. A bridge thing that just assumes the device will "do
the right thing", and is therefore unable to detect strange device
activity, is a bridge thing you do not want attached to your
system... you certainly don't want it procesing any of your valuable
data.


***  Hale Landis  *** [EMAIL PROTECTED] ***
*** Niwot, CO USA ***   www.ata-atapi.com   ***


Subscribe/Unsubscribe instructions can be found at www.t13.org.

Reply via email to