This message is from the T13 list server.
> > http://support.microsoft.com/default.aspx?kbid=813908 > > SCSI Pass-Through Mode Sense Command May Crash the Computer ... > From: Eschmann, Michael K [mailto:[EMAIL PROTECTED]] > > ... this issue that MS reported has nothing to do with > odd "byte" issues that you've been, er, peddling. > MKE. Thanks for talking ... but I'm lost here, sorry. Yes I agree Microsoft kbid 813908 speaks of Win 2K crashing because an app passed thru a choice of cdb[4] AllocationLength arbitrary enough to be between 1 and 7, such as the 4 that T10 texts pretend means to fetch just the header, when the op happened to be x1A ModeSense6. But what did I say that could suggest that the real world unreliability of copy In just the header has much to do with the real world unreliability of Scsi-over-whatever transport of data lengths that aren't multiples of large powers of two? Ok, they are both real world unreliabilities. They both come from Microsoft & friends, no matter how carefully compliant the device is. They both appear in the field when an app ships without prior out-of-band coordination of such things as specifically which mode pages exist in which device. But beyond that, there's not much of a connection, is there? > > what did I say In fact, I hardly said anything. On purpose I hardly said anything, specifically to try and avoid provoking any controversy this time around. I quoted Microsoft. I titled the email. I hit Send. Where did I go wrong. Maybe the connection is saying "TO [EMAIL PROTECTED]" together with "FROM [EMAIL PROTECTED]"? This alone made you think of odd byte lengths? As I believe we are alluding, yes I do visit [EMAIL PROTECTED] from time to time to try and discover how to explain how utterly unreasonable it is for device folk to expect Microsoft to pass thru such standard T10 commands as -x "12 0 0 0 05 0" -i x05 // i.e. Inquiry of the AdditionaLength, given a foundation of no more than merely standard T13 Atapi protocol. I don't remember how much of my failure to present that argument clearly has been copied here to t10 before now. As was reported to t13, I'm still working offline with Hale Landis to try and make the issue more plain. (Last I checked, Hale hadn't agreed that the issue exists outside my imagination. But we're working towards understanding each other.) Part of what's interesting about transport becoming unreliable only when one vendor's software tries to work with another vendor's hardware is that noone with money much cares. Any specific case can be fixed with adequate cooperation between software and firmware. I just personally think that for our standards to be fictional in this way is a Bad Thing. I don't think other people should have to repeat my history of pain. > FYI, this is an issue with the Microsoft driver > (supplied with their Windows 2000 OS) Yes Microsoft says Atapi.sys is the "cause". On the other hand, Apple Mac OS X folk have been heard to argue that pass thru is altogether a bad thing, for the bootable PDT x 00 05 07 0E. > is not converting the SCSI 6-byte CDB to the > 10-byte CDB format. I'm not sure I follow what you mean here. Microsoft doesn't reliably pass thru op x1A ModeSense6 to a device. Instead, sometimes Microsoft helpfully substitutes an approximately equivalent op x5A ModeSense10. In Win 2K vanilla, SP1, SP2, and SP3, this helpful approximate substitution crashes the kernel unless Cdb[4] is outside 1..7. I wonder if this helpful approximate substitution was designed to baby Microsoft filesystems: to try and help them ignore the brutal reality that SCSI and ATAPI devices differ over how they support op x1A ModeSense6 and op x5A ModeSense10. Then making the pass through less transparent could have been purely accidental, rather than necessarily designed to baby unaware pass through apps. > ATAPI drives don't understand the 6-byte format of > "Mode Sense" (am I wrong?), As I perhaps inaccurately remember this ... Once upon a time, ANSI made op x1A ModeSense6 required, op x5A ModeSense10 optional, for PDT = x00/05 DASD/CD devices. SFF came along and required op x5A ModeSense10, after redefining in an only slightly binary incompatible way. Now suddenly Cdb[1] & x08 DBD = 0 Reserved was supposed to mean what DBD = 1 had meant. SFF left an Atapi device free to implement ANSI x1A or not. The devices that implement both work better, especially across platforms. I've been told that later on SFF fixed their Cdb[1] text to agree with ANSI. I imagine the work of changing SFF texts re Cdb[0] to agree with ANSI remains a work in progress, but I don't know. > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > ... > Most ATAPI tape drives understand the 6-byte CDB. > Some support the 10-byte format, as well. Interesting thanks. > The act of supporting the 10-byte CDB implies to > <some> drivers that the device is a CD-ROM type of > device.... leading to the driver getting confused. Yes. I'm painfully vague on precisely what triggers Microsoft to decide to obstruct the pass thru of op x1A ModeSense6. I just know it happens sometime, out here in that binary code only land of "currently, there is no" source "licensing program for IHV’s". Pat LaVarre
