SAM-3 byte alignment change in 03-002r3

Pat LaVarre LAVARRE at iomega.com
Fri Jan 31 10:00:00 PST 2003


* From the T10 Reflector (t10 at t10.org), posted by:
* "Pat LaVarre" <LAVARRE at iomega.com>
*
> Otherwise, the transport protocol can only support
> commands that perform multiple-of-n byte transfers
> (where n is protocol-specific, since there's no
> requirement in SAM-3 any more).
 
Personally I'm too ignorant of SAM to understand all
the English of this thread, but ...
 
I can attest that actual laptop/ desktop
SCSI-over-whatever schemes are progressively failing
to support more and more of anything but data lengths
equal to (N * (1 << P)) where P increases over time.
 
Below, for example, is a soft trace of Win XP
rounding DOWN, yes DOWN, the length of data copied
intact, to the nearest multiple of 2.
 
And on the web we have Win ME rounding Up to N * 4:
http://members.aol.com/plscsi/20020328/oddwinme.txt
 
The most commonly used elements of standard protocol
seem quietly designed to duck this issue, by allowing
the sender of data always to make available
(N * (1 << P)) bytes, up to about 32 bits or so?
 
Should be fun to watch -x "12 0 0 0 24 0" -i x24 i.e.
an op x12 Inquiry of up to x24 begin to break on
64-bit desktop/laptop systems.
 
---

What I've seen most intimately are the failures of a
vendor-specific command naively designed to require
accurate transfer Out of arbitrary data lengths
between 1 and x20.  (Please may that vendor remain
forever anonymous.)
 
Out of One byte seems to be most commonly broken, no
matter that on paper it forms part of the standard x3B
WriteBuffer option.
Microsoft: SCSI Pass Through Fails with Invalid User Buffer Error [-X Sptd -i 1 (or -X Sptd -o 1)] 
http://support.microsoft.com/default.aspx?scid=kb;en-us;q259573
 
Pat LaVarre


	-----Original Message----- 
	From: Pat LaVarre 
	Sent: Fri 1/31/2003 9:29 AM 
	To: forum at t13.org 
	Cc: 
	Subject: [t13] Atapi odd H = C = D breaks
	This message is from the T13 list server.
	
	I have another soft trace to contribute, though I'm not yet caught up on all the e-mail.
	
	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.
	
	Increment H without changing C, thus presumably without changing D, and lookathat, an extra byte passes thru.
	
	I find this disturbing.  First because it's a case where TalkLikeWindows doesn't bless H = C = D.  Also because I know of driver stacks that try to save time by copying only the bytes that pass thru.  A stack that applies this optimisation sometimes but not always will end up leaving the last byte of H completely undetermined i.e. neither copied from the device nor reliably equal to the value it had before the pass thru began.
	
	Happy Friday, Pat LaVarre
	
	P.S. In every test, as expected for Win Atapi, we see a false report of H bytes copied.  (That is, we know we saw SCSI_PASS_THROUGH.DataTransferLength pass back unchanged, because we see the "main exit int" is zero.)
	
	P.P.S. Here now is the soft trace.  C is at offset 4 in the -x $cdb.  H is the -i arg.  The plscsi -d option asks for a trace of data before and after the pass thru, overriding the just-after default for -i.  To repeat this experiment, you can get plscsi in source or .exe at:
	http://members.aol.com/plscsi/
	
	D:\>ver
	
	Microsoft Windows XP [Version 5.1.2600]
	
	D:\>plscsi \\.\E: -v -x "12 0 0 0 06 0" -i x6 -d x8
	x 00000000 12 00:00:00 06 00 .. .. .. .. .. .. .. .. .. .. "R@@@F@"
	x 00000000 AE:AE:AE:AE AE:AE:AE:AE .. .. .. .. .. .. .. .. "........"
	x 00000000 05:80:00:31 5B:00:AE:AE .. .. .. .. .. .. .. .. "E@@1[@.."
	// 0 = plscsi.main exit int
	
	D:\>plscsi \\.\E: -v -x "12 0 0 0 05 0" -i x6 -d x8
	x 00000000 12 00:00:00 05 00 .. .. .. .. .. .. .. .. .. .. "R@@@E@"
	x 00000000 AE:AE:AE:AE AE:AE:AE:AE .. .. .. .. .. .. .. .. "........"
	x 00000000 05:80:00:31 5B:00:AE:AE .. .. .. .. .. .. .. .. "E@@1[@.."
	// 0 = plscsi.main exit int
	
	D:\>plscsi \\.\E: -v -x "12 0 0 0 05 0" -i x5 -d x8
	x 00000000 12 00:00:00 05 00 .. .. .. .. .. .. .. .. .. .. "R@@@E@"
	x 00000000 AE:AE:AE:AE AE:AE:AE:AE .. .. .. .. .. .. .. .. "........"
	x 00000000 05:80:00:31 AE:AE:AE:AE .. .. .. .. .. .. .. .. "E@@1...."
	// 0 = plscsi.main exit int
	
	D:\>
	
	

*
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org




More information about the T10 mailing list