On Sat, 1 Feb 2014, Steph Nguyen wrote:
On Sat, 1 Feb 2014, Steph Nguyen wrote:
Hi
It seems that when sending SCSI commands over USB, the kernel doesn't
necessary build a sense response. For instance, when sending REQUEST
SENSE over ehci, the scsi_cmnd->sense_buffer is left NULL; if I run the
same REQUEST SENSE command over a direct SCSI connect, the kernel builds
the scsi_cmnd->sense_buffer.
There's no need for the kernel to build a sense buffer when sending a
REQUEST SENSE command. That command always succeeds, so there's no
reason to ask for sense data which might explain why the command
failed.
I'm using sg_requests. When running it against a disk attached to a usb
port, the sense_buffer is simply empty. When run against the same disk
directly attached to a scsi controller, the sense_buffer is built by the
kernel. So same device, same command, two different hw paths lead to two
different behaviors.
Hold on a second. Above you said "build a sense response" and
"scsi_cmnd->sense_buffer is left NULL". Those are two different
things.
In one case we would have scsi_cmnd->sense_buffer == NULL. In the
other case, we would have scsi_cmnd->sense_buffer != NULL and
scsi_cmnd->sense_buffer[i] = 0 for each i.
Which do you really mean?
I mean scsi_cmnd->sense_buffer == NULL;
In general, usb-storage doesn't touch scsi_cmnd except to set
scsi_cmnd->result. (There are a few exceptions, but this is mostly
true.)
Right, it makes sense that the scsi subsystem takes care of this. But,
looking at drivers/usb/storage/cypress_atacb.c, I can see that the sense
buffer for ATA_16 is built by the kernel. So I suppose this is one of
these exceptions you are referring to.
No. Even in cypress_atacb.c, usb-storage does not assign anything to
scsi_cmnd->sense_buffer. That is, it does not do anything like
scsi_cmnd->sense_buffer = X;
However, it does fill in the contents of the sense buffer. That's as
it should be; usb-storage fills in the sense buffer contents for any
command that completes abnormally.
The reason you didn't see anything get filled in for your REQUEST SENSE
command is because the command completed normally.
I have no idea what happens with other SCSI transports.
To be clear, here's what I meant by "build" - I'm just pasting the
relevant bits of the code:
static void cypress_atacb_passthrough(struct scsi_cmnd *srb, struct
us_data *us) {
...
unsigned char *sb = srb->sense_buffer;
...
if ((srb->result != (DID_ERROR << 16) && srb->result != (DID_ABORT <<
16)) && ...)
memset(sb, 0, SCSI_SENSE_BUFFERSIZE);
...
sb[0] = 0x72;
So, unless I'm completely misunderstanding the code, here the command is
supposed to have completed successfully, isn't it? And the
sense_buffer[0] is filled with 0x72 when it completes successfully.
Alan Stern
Thanks
Steph
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
