** This is the quasi-official and semi-temporary T13 email list server. ** > Some people have said ... > if IO and CD are incorrect ... > their driver will signal a > "phase error" The commodity Usb1/2 to Atapi bridges most familiar to me does exactly this for any PIO transfer. At least in part because I said that was the least awful design choice available. > "phase error" (whatever that is) UsbMass properly distinguishes Passed, Failed, and Other. Ansi Ide specs - and many other more academic efforts - have traditionally left Other quietly undiscussed and unenumerated. This ignores a large part of what lies beneath real trouble in the real world. A popular example of Other in Ide would be if a Pcmcia Atapi device clears x3F6 & x89 BSY:DRQ:ERR because it was separately power-cycled and some reckless host accepted that as good status no matter that (x1F2 SectorCount & x03 IO:CD) != x03 Status. > But so what, just ignore IO and CD then you don't have to worry In the disk drive business this approach to host code is known as miscompare-by-design. We're talking here about what is the appropriate degree of conscious redundancy. Some people are in the Zero camp. By way of reaction, I live usually in the as-much-as-I-can-persuade-you-to-swallow camp. I expect Optimal is somewhere in the middle. > "phase error" (whatever that is) "Phase error" is a term for the most common forms - synchronisation-lost forms - of Other. The term comes from Scsi. The synchronisation in question is of a host state machine trying to move command, data, and status with a device state machine trying to do the same. The host state machine by definition expects to move at most N bytes of data out or in. If the device state machine tries to move data the wrong way, or tries to move more than N bytes, then for most interfaces the results you get vary by the combination of host and device vendor you recklessly chose to trust with your data. These are "phase errors", for which, to my knowledge, only Usb Mass bothers to specify specific recovery. These occur commonly because of some confusion in the overwhelming details of everything that crosses the bus that is not read/write. These occur more often when using protocols that neglect to follow the Ata precedent of insisting that all hi-speed data movement be a multiple of x200 bytes and insisting that any command can be designed to return as many as six bytes of "status". > Of course one must compare CD and IO results to what is expected! Aye, the point here is to be consciously redundant. This is about separating network layers, like in the ISO model. Suppose you try to write an Atapi driver so that it can move command, data, and status without understanding the command ... like, say, you're designing a small cheap Usb/Atapi bridge. Well then, what do you do when the host is wrong about how much data it expected to move which way. How do you even tell the host it was wrong. Casually, it looks to me like people generally let the device win on direction and let the host win on count. > let the device win on direction That is, host software that uses read-only-memory to write the device page-faults when the device disagrees about direction. Other host software just quietly corrupts memory it does not own. > let the host win on count They actually toss data in/ fabricate data out to try and persuade the device to stop moving data. > > "phase error" (whatever that is) > UsbMass properly distinguishes Passed, Failed, and Other. Other can also include a plethora of things that are Not Supposed to happen. For example, host sampled x3F6 AlternateStatus before writing x1F7 Command and found either of x88 BSY:DRQ set or x40 DRDY clear. In Atapi, host sampled x1F5:1F4 ByteCount and found zero. Etc. etc. etc. In Scsi/Atapi/etc., it's crucial to distinguished Failed from Other because an automagic op x03 RequestSense is appropriate only for Failed. Issued after Other it's quite likely to crash a host designed not to expect Other during the automagic and it's quite likely to return SK:ASC:ASCQ NoSenseInfoAvailable which is then likely to be misinterpreted as NoError. Decidely a Bad Idea(TM). Pat LaVarre -- If you have any questions or wish to unsubscribe send a message to Hale Landis, [EMAIL PROTECTED] To post to this list server send your message to [EMAIL PROTECTED] For questions concerning Thistle Grove Industries or TGI's list services please send email to [EMAIL PROTECTED]
