This message is from the T13 list server.
Pat, Just to comment on the following: "What's difficult between people is getting you to agree your host is broken, or me to agree my device is broken. By definition a bus trace can only show disagreement. Who is at fault is then a matter of human judgment - a matter of reasonably applying the natural language text of the standard." While ultimately these things are a matter of human judgment, not all human judgments are equal. A lot of people who participate in these mailing lists are experts in various areas (for instance, they wrote the actual standard) - and are weak in other areas. Many of the participants know each other, and so realize the particular strengths and weaknesses of one another. For instance, I've know Hale and Harlan for over 10 years now, and appreciate that they frequently have a better understanding of some issues (especially host side ones) than I do. But a lot of people don't know one another, and that can lead to frustration. I try to restrict my strong assertions to areas where I do have a strong expertise (not to be confused with infallibility :-)). So when I say that a host is not ATA compliant under certain circumstances, I generally really mean that, based on a greater than average understanding of the issues involved. Jim -----Original Message----- From: Pat LaVarre [mailto:[EMAIL PROTECTED]] Sent: Friday, February 15, 2002 1:30 PM To: [EMAIL PROTECTED] Subject: [t13] less than all hosts & devices disagree over byte counts? This message is from the T13 list server. Hale & Jim: Hello again, and thanks again for working to clear the fog in my mind. > Just what are you talking about anyway? Just now? A recent restatement by you-know-who of an old, vehemently refuted, patently false claim - the claim that the standard Atapi C/D I/O redundancy accomplishes nothing in the real world. > Subject: [t13] doing a big favor > From: [EMAIL PROTECTED] > Date: Thursday - February 14, 2002 4:46 PM ... > I am not about to propose or support changes > to the ATA/ATAPI standards > to cover BROKEN DEVICES (or BROKEN HOSTS). I imagine we can all agree vehemently with this recurrently SHOUTED statement, though I don't recall you supporting the proposal to pollute Ata with Sff Atapi either. Repeatedly SHOUTing "broken" won't help us share knowledge here. We need new words to make progress. To my ear, the word "broken" is a very broad word with judgmental connotations. A phrase like "rightly assumed not to exist commonly" is rather more specific and objective - an almost scientific hypothesis we can cooperatively work to confirm/deny in the real world. Is there a phrase in between over which we can agree? What's difficult between people is getting you to agree your host is broken, or me to agree my device is broken. By definition a bus trace can only show disagreement. Who is at fault is then a matter of human judgement - a matter of reasonably applying the natural language text of the standard. A popular technique for getting people to agree over what bus traces mean is to divide the discussion into architectural levels. For example, suppose at one level we can agree about how many bytes moved which way. Well then, at some higher level we can try to agree about what those bytes mean. > Subject: [t13] but we say the disagreeable hosts are broken > From: "Mcgrath, Jim" <[EMAIL PROTECTED]> > Date: Wednesday - January 30, 2002 8:00 PM ... > in some DATA OUT cases you see more ... bytes > being transferred than you would expect > given the command being executed .. ... > the ATA standard clearly states that the host is broken In my judgement, (-: which I find reasonable, :-) the Ansi Atapi standard cannot meaningfully claim the host has violated protocol when an Atapi host guesses wrongly how many bytes an Atapi device will actually try to move which way. 1) Built into the Ansi Ata/pi standard is the idea that an Ata or Atapi device may cut any transfer short. 2) The Ansi Atapi standard doesn't tell the Atapi host HOW to guess how many bytes an Atapi device will actually try to move which way. 3) Standards for Scsi transport vary in how effectively they let the host and the device share knowledge of how many bytes each wants to move which way. > 1) Built into the Ansi Ata/pi standard > is the idea that an Ata or Atapi device > may cut any transfer short. 1a) The Ansi Atapi standard does not tightly bind the idea of cutting the transfer short to reporting an ERR. 1b) Indeed, such a tight binding so plainly stated would clash with Atapi Cdb standards that permit transfers of data In to be cut short (e.g. x 12 0 0 0 FF 0 Inquiry up to xFF bytes). 1c) Indeed, such a tight binding so plainly stated would clash with Atapi Cdb standards that permit meaningful data In to be transferred together with an ERR (e.g. the mode sense page x01, byte x02, mask x20 TB "transfer block in error" bit). > 2) The Ansi Atapi standard doesn't tell the host > how to guess HOW many bytes > an Atapi device will actually try to move which way. 2a) The Ansi Atapi standard doesn't comment on Atapi ops - the first byte of the Cdb aka the packet. Instead, the Ansi Atapi standard describes only the most commonly used Ata ops. 2b) By definition no standard can tell the host how to guess when the op in question was not standardised before both the host and the device shipped. 2c) No standard can account for equally reasonable but disagreeing interpretations, except by growing less unclear over time. Meanwhile, we all still have to communicate, preferably without crashing the o.s. > 3) Standards for Scsi transport > vary in how effectively > they let the host and the device share knowledge > of how many bytes each wants to move which way. 8 bit asynchronous Scsi, AtapiPio, and friends let a device ask to move a fully arbitrary count of bytes either way. In Atapi Pio, the technique is for the device to supply an indefinitely long series of samples of (x1F2 & x03) C/D I/O bits and the x1F5:1F4 ByteCount, with the unnecessary proviso that no byte count before the end may be odd. Usb Mass BBB & 1394 Sbp3 let a host ask to move a fully arbitrary count of bytes either way, up to a small limit per Cdb e.g. 4GiB for Usb Mass BBB. I know Usb Mass BBB lets the device report residue to the byte, I've heard 1394 Sbp3 has similar capabilities. Any less arbitrary standard for interconnection by definition can't support all the traffic that those other wires can bear. > compelling real world problem I'd say Jim's clear objective call for specific examples of communication that breaks is neither difficult nor yet trivial to satisfy with a demo on the desktop. For example, in 1394, it's easy for a device to lie about residue inadvertently. There N bytes can transfer without all N appearing at offsets 0..N-1. I know this, I've seen this ... but I can't easily SHOW you, not yet. Offline I'm working to make this kind of demo trivial; I'm writing a few thousand lines of C source to let a demo like this become a matter of a pasting in a couple of command lines. I imagine I will never be authorised to share current examples involving products made by the people who employ me. Indeed, here I neither confirm nor deny that such examples exist. Rather, I hope to make it easy to gather examples from widely distributed products made by other folk. My personal history of pain, mass storage since 1994, leaves me confident that LOTS of such examples do exist, outside of read/write of x200 byte blocks. > less than all hosts & devices disagree over byte counts? I have never in my life seen anything not broken according to the paper standard, not when I was paid well enough long enough to invest the time to really go find out. I've even seen a five year old child crash an Apple Mac, running software from more than just the one vendor you may have in mind. The closest to perfect I recall ever seeing is the wiggle room designed into Sff Atapi. Those standards say specifically to zero the ([x2] & x07) ansiRevision field of the op x12 Inquiry data. This painfully clever trick avoids identifying a particular Ansi Cdb standard as applicable. Without a clearly applicable Ansi Cdb standard, we can't quite say that any Atapi host or device does violate an Ansi Cdb standard ... ... and yet we know in the real world actual devices do confuse the Ansi hosts that aren't conservative enough to refuse to talk to a device that does not identify an applicable Ansi standard. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org. Subscribe/Unsubscribe instructions can be found at www.t13.org.
