This message is from the T13 list server.
> [t13] doing a big favor > From: [EMAIL PROTECTED] > Date: Thursday - February 14, 2002 4:46 PM ... > host device This is an interesting slip of the keyboard. At least, to my ear, the phrase "host device" is not meaningful in English. Rather, all the interesting vagueness here comes alive in how one chooses to convert from the phrase "host device" to a concrete and specific divison of responsibilities between host and device. > if the the command is a write ... > but the device ... read .. > I sure hope this host device will detect the error! Ansi compliant Atapi Pio host of Ansi compliant Pio device? Can do (have done). Other Ata/pi data transfer modes fall short here. In Atapi, device silicon can always see these errors - but some hard-coded (i.e. not fpga) Atapi device silicon designed without this error in mind hides these errors irretrievably from firmware. > > Curtis Stevens ... > > the host side ... firmware is not broken There's that "broken" word again. > if the the command is a write ... > but the device ... read .. > I sure hope this host device will detect the error! These two cases appear among the thirteen ways in which hosts & devices commonly dis/agree over how many bytes to move which way. Generic UsbMass numbers these cases in "6.7 The Thirteen Cases" of: <http://www.usb.org/developers/data/devclass/usbmassbulk_10.pdf> In my personal history of pain, these particular cases have been the least common. "Hi <> Do" is the shorthand for case 8 of 13: the host expected to move data in but the device actually tried to move data out. "Ho <> Di" is the shorthand for case 1 of 13: In my personal judgement, of the 13, these two cases occur least commonly. In my personal history of pain, I have seen these cases occur only when a middle layer of the host decided direction by looking an op up in a table, rather than trusting the software that constructed the Cdb to know what it means for the device in question. I hear today Linux still works this way ... but that could easily be unfounded slander. > if the the command is a write ... > but the device ... read .. > I sure hope this host device will detect the error! > > Pat LaVarre ... > > Other Ata/pi data transfer modes fall short here. All the Atapi Dma data transfer modes that lack the I/O bit, whoops. (((I think I remember, I trust people will here correct me as needed ...))) A host that tries to move data the wrong way in Ata/pi Pio, SwDma, or MwDma thereby steps outside of the standard - such a host provokes an indeterminate response. A host that tries to move data the wrong way in Ata/pi UDma most naturally hangs - I know of shipping hosts observed to behave this way. But I'm told UDma puts enough info on the bus that some host silicon is smart enough to detect and complain of these errors. Pat LaVarre > Subject: RE: [t13] doing a big favor >>> [EMAIL PROTECTED] 02/14/02 04:37PM >>> ... Curtis Stevens said... >Further, if the host side is designed with independent >state-machines to read data and to send commands the IO and CD >bits become very important. I am aware of some firmware that >works this way... The firmware is not broken because IO and CD >are well defined in the specification as to how they operate >during data transfers. So if the the command is a write command but the device messes up and sets IO and CD to indicate a read command I sure hope this host device will detect the error! ... Subscribe/Unsubscribe instructions can be found at www.t13.org.
