This message is from the T13 list server.
> > 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. Well, sure. Windows i/o ships as binary code only, unlike much of Mac OS i/o, for example. Of course Windows i/o is & will remain broken. But what is it about the T13 texts that fails to get 'the H = C = D should work' message across to Microsoft? Why aren't -x "12 0 0 0 05 0" -i 5, and -x "12 0 0 0 00 0", and so on a core part of what Best Practices tell every careful programmer to run on a new Atapi driver stack? Can we do anything to help H = C = D can work, besides publishing our own test software? Once upon a time a people manager told me that less than all the world thinks of life in terms of truth tables, for which every cell must be visited, or you're not done. How strange. > 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 ... Me too. > then the OS driver stack "lost" that last byte of > data somewhere inside the OS driver stack Yes. > Or better yet, anyone from this OS vendor care to > tell us which "service pack" fixes this OS driver > stack bug? Microsoft doesn't make it easy to report I/O bugs unless you have a paying business that will benefit directly from fixing them. I've been working since July 2002 to explain that -x "1A 08 3F 0 04 0" -i 4, i.e. a ModeSense6 of just the header, takes down the kernel, whoops (whenever Win2K op x1A/5A ModeSense6/10 translation is in effect). I have hopes of success in 2003 ... ... but I cheated. I used a paid channel to Microsoft from Iomega that was expiring unused at the end of 2002, just because I know good people at Iomega, not because Iomega will directly benefit if ever Microsoft does publically acknowledge this limitation. If it takes me seven months or more to say that the kernel crashes, it might take me the rest of my life to say that a byte gets dropped when an app wasn't written with the Microsoft redefinition of Atapi in mind. Or maybe having credibly reported a kernel crash will make contacts for me with whom I can discuss lesser issues. We'll see. Contrast that process with the quasi-public: http://search.java.sun.com/search/java/index.jsp?and=p.lavarre&col=javabugs&rf=1 With Sun, merely posting truth can influence something as significant as the definition of an executable .class: http://developer.java.sun.com/developer/bugParade/bugs/4614120.html That's a bug parade that works, though no doubt Not such an independent profit centre in its own right. Curiously enough, though the URL remains bugParade, the pointy-haired folk at Sun changed the label to say "Bug Database". Clearly those folk don't get it. Bugs shouldn't be, but are, normal. > > 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". Thanks for saying. Welcome to my world of pain. > 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? Those requirements are paper only. What the device vendor really has to do is persuade the WHQL .exe's to report Passed. I imagine -x "12 0 0 0 05 0" -i 5 isn't yet part of WHQL. Whoops. > 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). It may be that the plug 'n pray architecture of Win NT etc. doesn't conceive of a Scsi transport that can't count bytes or that chokes unless data length is aligned. I'm reasonably ignorant here, but as far as I know, via ioctl (aka DeviceIoControl) a driver can only report that it needs aligned data addresses: Microsoft IOCTL_SCSI_GET_CAPABILITIES http://msdn.microsoft.com/library/en-us/storage/hh/storage/k307_8c6q.asp Of course, needing aligned data lengths is commonly true of Windows Atapi driver stacks, just not reportable. > THIS OS VENDOR NEEDS TO RESPOND. > Your response may be the only thing that will make > Pat happy! Pat happy? Surely that would be less fun. Did you not hear? Whether or not the H vs. D "13 cases" matrix matters eventually split the Usb Mass community. There we now have two competing data transport standards, one with the matrix, one without. (And the one without is dying, though arguably not for that reason alone.) Cheers, Pat LaVarre
