This message is from the T13 list server.
> Are unexpected/unplanned "resets" really that much of a problem? What's a "reset"? Umm, if possible, let's not go there, in honour of the past discussion of x1F7 Command = x90 ExecuteDeviceDiagnostic, except to say that yes it's nice to have a way to say that x03 StatusIn was unexpectedly not reached. Writes of x1F7 Command with BSY:DRQ nonzero are a real problem. The o.s. and the power management Bios don't always accurately negotiate who owns the bus. I've seen Bios interrupt the o.s. and branch on just BSY, not bothering to check DRQ. > What if the last command > to the ATAPI device was ... ATA ... > There is no IO or CD bits at the end of these commands In practice Ata commands to an Atapi device are pleasingly rare, in part because we Ansi folk didn't get around to defining a protocol for distinguishing their non-ERR results from a reset. I hear the community is divided over how to handle plug 'n play and power management errors. The theory is, if the block read/write appears to work, then the plug 'n play and power management must have been good enough. > If an ATAPI device is "reset" > it should have a SK=6 ASC=2x Unit Attention error to report. Way too late. Scsi 2 unit attention protocol is separated from by matches word-for-word the deferred error protocol. Remember the deferred write errors we discussed recently? Indeed these are useful in manufacturing & test: if ever you do see one, you freak out, you go find out why, and you make it not happen in the field. But in the field, unit attentions are useless (except for multihost Scsi, which isn't relevant when we're talking about Atapi). > I have never heard an ATA ... Ata people commonly address very different markets. Removing the media without also removing the device is far far far less common. > Are unexpected/unplanned "resets" really that much of a problem? Power cycles? Maybe yes, maybe no. I'm aware of this issue because our in-house tests showed that the some of the Atapi drivers that ship with one or another flavour of Microsoft Windows report read/write succeeded if a Pcmcia powered Atapi device power cycles separately during the read/write. That suggests these host folk aren't counting bytes transferred and aren't checking C/D I/O = x03 StatusIn. Our in-house drivers don't have this problem. Rather than saying "miscompare" i.e. we have read back something not written, they see that the power cycled command involved an "unexpectedly bus free" condition. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
