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.
Your question isn't very precise. How did you "run" a REQUEST SENSE
command? When using usb-storage under normal conditions, the SCSI
layer doesn't ever send that command.
So is there a reason why usb-storage doesn't build the sense buffer?
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.)
If the SCSI layer wants to receive sense data, it has to set the
scsi_cmnd->sense_buffer field itself. Normally it does so. For
example, see what happens when the SCSI layer issues a TEST UNIT READY
command to usb-storage.
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.
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
