This message is from the T13 list server.
> Unfortunately, OS driver/software shows incorrect data transfer direction > to PATA in some cases. Yes. The taxonomy of normal disagreements over how much data to copy which way, taken from the specifications for how to pass SCSI thru USB, but then boiled down to Three cases from the usual Thirteen, becomes: a) host & device agree in length and direction b) host & device disagree in length but agree in direction c) host & device disagree in direction Here we have focused on case (c). > ATA/ATAPI specification does not allow any time-out of device > interface. So if data transfer direction is incorrect, it hangs up. > Host may check its timer, then may issue Reset to device. ATA/ATAPI UDMA hangs in case (c), seemingly by design, yes. Vendors before now have solved this by copying out a DIR bit in x1F2 before op xA0 Packet time, yes. > This causes problem in P1394/USB-ATAPI bridge board Yes. > actually. SATA-PATA bridge should have some knowledge of SCSI ope-code too. By definition this idea of an "opaque" bridge breaks for vendor-specific and newly-standard ops that the old bridge misunderstands. SCSI thru USB to ATAPI, and SCSI thru FireWire to ATAPI, both work because in those protocols the host explicitly says how many bytes of data it expects to copy which way. Does SATA have no similar provision? Ouch. > ... Kindly offline I heard a delightful & relevant application to bridge design of the Internet interoperability principle "Be liberal in what you accept, be conservative in what you send". In bridge design, we have to choose. We can choose to trust an opaque bridge to translate the command, or we can choose to pass trouble thru a transparent bridge. An opaque bridge is not liberal in what it accepts. A transparent bridge is not conservative in what sends. Ouch. We conclude: bridges by definition cannot be well-designed. But against that theory we have one confusing counterexample. Certain USB/ ATAPI PIO bridges actually do work well in practice. With those, the host begins by passing to the bridge a complete description of how the host would have spoken ATAPI PIO. The bridge at least once invisibly negotiates max PIO mode and thereafter transparently reproduces how the host would have treated a direct-attached device. And the system works. By contrast, bridges to ATAPI DMA don't work quite so well. The standard description of how the host would have spoken ATAPI PIO doesn't mention how the ATAPI DMA host would have miscounted bytes with a direct attached device, so the bridge can't reproduce that behaviour exactly. Pat LaVarre
