I have a USB bridge that's implementing SAT passthru cdbs. We ran
into an
issue with the usb-storage driver in that when it does auto-sense
(because
the CK_COND bit is set in the passthru cdb), the driver does a
sense with
only 18 bytes for the sense buffer. The problem is that SAT
passthru wants
to return 22 bytes of sense data. The last 4 bytes that don't get
returned
are fairly important ATA task files registers: lba high hob, lba
high,
device, and status.
For testing purposes I use the patch below, but what's the correct
way to
deal with this issue? Is there something in the USB spec
mandating 18 bytes
of sense data, or is the usb-storage simply making a hard-coded
assumption?
I believe it's a hard-coded assumption, based on the observation
that many
USB devices don't like it if you ask for more or less than 18
bytes. Matt
Dharm can correct this if I'm wrong.
The sense buffer length is yet another quantity that ought to have
an SG
passthru but doesn't.
The spec here is de facto, not de jure.
De jure, the host should only send SCSI op x03 "Request Sense"
requests that allow the max of xFF (255) sense data bytes in, because
these requests are defined as the obscenity of a read-and-clear
request. A host that instead rudely asks for less than all possible
sense bytes risks irrecoverably discarding sense bytes before the
device reports that they exist, thru the additional length byte.
Hosts have that right only when out-of-band they know enough about
the device to predict what the additional sense length will be.
De facto, best as I mis/remember, Windows ME/ 98/ 95 asked often for
x0E (14) bytes and Win XP/ 2K/ NT now asks often for x12 (18) bytes.
Furthermore, Windows ignores the additional length byte.
Consequently, naturally, yes, because of the rudeness of those many
hosts, now many commodity peripheral storage devices choke over a
request for anything other than x12 (18) bytes, and give the host
zero or other noise in the additional sense byte.
///
That myth or truth explains why device vendors have learned to extend
sense data with vendor-specific requests, rather than pretending that
the additional length of sense data can grow. Fun to see the SAT
passthru folk violate this folk wisdom by adding a new form of
Command Out without adding a corresponding new form of Status & Sense
In. They may have enough weight to change this reality, we'll see.
///
Another significant influence over sense data lengths is the chaos
triggered by misalignment.
Various Windows services round up any length to the next four or
eight byte boundary, possibly abusing kernel privilege to write
memory not allocated. Some apps therefore depart from the x0E/12
standard and ask for x10 (16) bytes instead.
Now we see SAT passthru needs x16 (22) bytes, more than the currently
conventional x12 (18).
Soon enough we'll see if the next new de facto requested sense data
length is x10, clashing with SAT passthru, x14 for 32-bit alignment,
or x18 to satisfy 64-bit alignment and SAT passthru.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Linux-usb-users@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
