This message is from the T13 list server.
On Thu, 11 Apr 2002 14:03:00 -0600, Pat LaVarre wrote:
>This message is from the T13 list server.
Pat: I have not read your document yet but I will.
>4) The discussion produced the attached claim that folk who
>implement the analogue to Atapi known as 1394a Sbp2 in practice
>quietly (i.e. without any applicable public spec) resolve
>host/device disagreements over byte count by copying from/to the
>host what the host asked, by copying to/from the device what the
>device asked, they flatly don't check for agreement.
I see confusion here. Here is a picture of a generic X-to-ATA/ATAPI
bridge:
System with X-to-ATA/ATAPI ATA/ATAPI
X-interface <----> bridge device <----> device
^ ^
this is an X | | this is an ATA/ATAPI
device ------------+ +--- host
The point here is that the X side, host and device, should be
implement according to the X interface standards. The ATA/ATAPI side,
host and device, should be implemented according to the ATA/ATAPI-x
interface standards.
If X is 1394 then you must realize that 1394/SPB2 has very basic
data integrity problems. SPB-2 can create direction mismatch
problems, problems with knowing how much data was transferred or if
any data was transferred. I will agree that many of these problems
are actually due to the way a PCI bus OHCI device is designed and not
something that can't be fixed in a well thought out 1394/SPB2
design.
I don't know anything about USB but from Pat's comments it sounds
like USB has some of these same data integrity problems.
But we don't have those problems on the ATA/ATAPI side of the
interface. ATA/ATAPI is built upon the idea that both host and
device know how much data all possible "write" commands will
transfer. And upon the idea that "read" commands have a maximum
transfer size but that in a few cases a device might transfer
less than that maximum. The only problem with DMA "read"
commands is the stupid host adapters we are stuck with don't tell
us how much data was transferred (this is not an ATA/ATAPI
interface problem). In summary, the bridge device is an
ATA/ATAPI host and an ATA/ATAPI host must be properly
implemented!
>My employer sells PC peripherals - the R&D folk lose something
>like half their opportunities to having to engineer everything
>two or more times. We're not solving this once. We're solving
>this again and again and again for an ever growing number of
>variations on how to pass thru Scsi traffic.
I think this is the problem... In an X-to-ATA/ATAPI bridge you don't
just "pass thru" SCSI commands. The bridge device must execute the
SCSI commands just as if it was a true SCSI device and it must in
turn do whatever is required on the ATA/ATAPI interface, following
all the ATA/ATAPI rules, to perform that emulation.
Yep, building bridge devices is complex and time consuming work.
However, if there was something in ATA/ATAPI that could be changed,
something that was not a major expense and did not break existing
designs, I am sure T13 would be happy to help. T13 has done several
things to bring CFA into the standards, I don't see why T13 would not
do other reasonable things that may be required for bridge device
designs. But to say that ATA/ATAPI is wrong or it is broken is not
fair. ATA is 16 years old and ATAPI is about 8 years old and both
seem to work just fine when implemented according to the published
standards.
>-----Original Message-----
>Date: 04/11/2002 11:08 am (Thursday)
>From: Pat LaVarre
>To: [EMAIL PROTECTED]
>Subject: Fwd: your roadmap towards a more transparent Sbp2
>
>Q1) Can your bridge firmware alter the content of
>"the status block" before your 1394a/Atapi bridge
>stores that block to "the status_FIFO address"?
A: Of course it can. Why? Because the bridge is the 1394/SPB2/SCSI
device and it must (shall) present status that conforms to the
1394/SPB2/SCSI standards (not according to the ATA/ATAPI standards).
>Q2) Can your 1394a/Atapi bridge firmware determine
>how many bytes of data your hardware copied from/to
>the attached Atapi device?
Absolutely. Because we know how much data is transferred by EVERY
command (ATA or ATAPI command, read or write) on the ATA/ATAPI
interface. We know this because this is one of the most basic ideas
of ATA/ATAPI. In my opinion trying to make ATA/ATAPI work like some
other interface shows a lack of understanding of the basics of
ATA/ATAPI. And since the bridge chip can be a "good" ATA interface
host (unlike those stupid PCI bus ATA hosts) it can know how much
data a read DMA command transferred.
>Q3) Can your 1394a/Atapi bridge firmware determine how
>many bytes of data your hardware copied from/to the 1394
>host? And how many bytes remain of the data_size or of
>the segment_length of the last page table segment used?
>And if more unused page table segments exist?
Maybe, probably, probably not... But lets not go into that here
on the T13 list. But the following discussion (from Pat?)
describes many of the 1394/SPB2 problems, and these are not just
problems with 1394/SPB2-to-X bridges, even native 1394/SPB2
devices suffer these problems,
>The bridges we've surveyed settled for one of two strategies.
>Some hang until reset (and when they hang, they hang til
>power-cycled no matter how many ManagementORB's you try sending)
>... the others quietly make up the difference in the middle.
>That is, they quietly discard data copied from the source or they
>fabricate data copied to the sink. They copy from/to the host
>what the host asked, they copy to/from the device what the device
>asked, they don't check for agreement.
>This reality shocked some of us.
Yea, what's new? Afterall we are talking about 1394, a wonderful
class project for some college computer science students but far
from something that should be used in real computer systems
processing real data.
*** Hale Landis *** www.ata-atapi.com ***
