This message is from the T13 list server.
On Fri, 31 Jan 2003 09:29:54 -0700, Pat LaVarre wrote: > This message is from the T13 list server. > > To speak concisely, I'll adopt a convention from elsewhere: > H = byte count host asks to copy > C = max byte count Cdb allows > D = byte count device asks to copy > > H = C = D does Not just plain work in Win XP, not for Atapi. At > least in the one counterexample below, when H = C = D but H is > odd, Win XP behaves as if H were H - 1, and quietly discards the > last byte of D. Then, as said before, this is a broken OS device driver stack. This has nothing to do with T13 or with the ATA/ATAPI-x standards (or even SFF-8020!). But I assume this OS driver stack actually transfers the last word of data on the ATA/ATAPI interface because if it did not it would leave the device "hung" with BSY=0 DRQ=1 status. Assuming there is no "device hung" condition here then the OS driver stack "lost" that last byte of data somewhere inside the OS driver stack - again, not T13's problem. Anyone from this OS vendor care to comment about this? Or better yet, anyone from this OS vendor care to tell us which "service pack" fixes this OS driver stack bug? > Increment H without changing C, thus presumably without changing > D, and lookathat, an extra byte passes thru. > > I find this disturbing. I would also find such a basic bug in an OS driver stack "disturbing". Please - Someone from this OS vendor needs to tell us why they are not following the requirements of the very documents (SFF-8020 and ATA/ATAPI-x) that they require the device vendors to follow? Or tell us that this OS devie driver stack does not support odd length ATA/ATAPI data transfers (claim this bug is a software restriction you just forgot to document - that way you don't have to fix any software bug). BUT PLEASE, SOMEONE FROM THIS OS VENDOR NEEDS TO RESPOND. Your response may be the only thing that will make Pat happy! T13 can't fix this problem for Pat - any fix would mean changing the way ATAPI works, including the most basic PACKET command protocol things going all the way back to SFF-8020! Hale *** Hale Landis *** www.ata-atapi.com ***
