This message is from the T13 list server.
> usually confusing ... > trying to modify the standard > to catch problems > that are due to people > not implementing the standard I emphatically agree we just dig ourselves in deeper if we grow standard X to fix people not reading standard X carefully in full. But here I mean to be asking to grow standard Y to withstand how commonly people differ over their interpretation of the darker corners of standard X. Disagreements over how many bytes should move which way with a command arise whenever plug 'n play fails less than completely. These disagreements arise when the designers of the host & the device only coordinate their understanding of normal life, not also the darker corners of what Scsi/SffAtapi commands mean when. I'm asking for us all jointly to make Ansi Atapi Dma optionally as effective as Atapi Pio in limiting how much chaos results when people get Scsi commands wrong. > in this case the CRC ... over ... 514 bytes ... > If the command was for 512 bytes ... > there is a host logic error > that the device should detect, I agree any Ide device, Ata or Atapi, easily can and all definitely should count the "residue" precisely i.e. how many bytes clocked across the bus that the device did not "willingly request". But I think we have no public mass storage protocol standard, except generic UsbMass, that mentions this case, much less tells us what SK:ASC:ASCQ Scsi error code to use to report it. Even if on paper someone can find or compose a standard, I regret to report we have broad, directly-attached Atapi precedent that stands firmly against letting any Atapi device report positive residue as an error. The broadest precedents require only that we tolerate postive residue for data in, aye. But we have precedents for data out, likewise. Specifically .... > in this case 514 bytes. > If the command was for 512 bytes, > then the host made an error > - it should have known better > and stopped at 512. Yes, should have. Meanwhile, I remain focused on making remote-attached Atapi be bug-for-bug compatible with direct-attached Atapi. > The windows tradition you are referring > to is I think the opposite case - > bytes being transferred to the host. > > ... well tested ... hosts sometimes are not > (i.e. the software counts on the device > not screwing up, and does not do > an ending count check). Agreed the more flagrant tradition for failing to see positive residue as an error is the case of moving read data in. Classically, the command x 12 0 0 0 FF 0 is a request to move all available Inquiry bytes, no matter how fewer than xFF bytes that may be, no matter if the total byte count moved is odd. Indeed, the only standard Scsi mechanism able to read all RequestSense data before clearing it is the command x 03 0 0 0 FF 0, which TYPICALLY works only if the host does tolerate postiive residue. > tradition Less well-known is the case of hosts that round up the expected i/o length to a multiple of the physical memory page size. With a host like that, as recently as Spring 2001, I heard of a proto bridge dying when it met an app that had allocated x90 bytes of memory to receive the data of the command x 12 0 0 0 FF 0 into a pinned physical page of x1000 bytes. This example works in a direct-attached system ... ... if plug 'n play connects the app only with devices that have <= x90 bytes of Inquiry data ... if the Atapi driver software shuts down Dma when the status INTRQ arrives, no matter that the Dma engine was initially wrongly instructed to move x1000 bytes ... if the Dma engine takes care to avoid writing more byte pairs to memory than in fact crossed the bus, even when the software rudely shuts it down prematurely. All these if's are true together commonly enough that when a supposedly transparent bridge gets them wrong, people complain. This was the use case that persuaded the UsbMass committee to let a device cut a scatter/gathered data transfer short. Mass Storage would have been a much better fit for core Usb if only we had been willing to try and change Scsi in the real world to tolerate always moving precisely as many bytes as the host asked to move. > the opposite case - > bytes being transferred to the host. Rounding transfer sizes up to the next largest multiple of physical page size is an i/o/virtualMemory optimisation that applies equally well to moving data in or to moving data out. > ... So there you have it. Broad, directly-attached Atapi precedent that stands firmly against letting any Atapi device report positive residue as an error. Broadest for data in, aye. But applicable for data out, likewise. What's the first design of any protocol upgrade? Don't break working code. I think we're stuck having any Atapi device merely report accurate residue. Maybe Ata can swallow a change to report positive residue as ERR, but not Atapi. Pat LaVarre Subscribe/Unsubscribe instructions can be found at www.t13.org.
