Jun/xen-devel,
Currently, if an error occurs as a result of a pvSCSI operation, the
sense data is automatically collected and placed into the sense buffer.
In my GPLPV drivers I tell Windows that my scsi ''adapter''
supports
AutoRequestSense, so when a pvSCSI gives me the result of the scsi
operation, if there is a check condition I put the sense data into the
sense buffer and tell Windows that the sense data is valid. It is
possible for Windows to set a flag on a scsi request called
SRB_FLAGS_DISABLE_AUTOSENSE, in which case I do not copy the data.
Symantec Backup Exec is setting SRB_FLAGS_DISABLE_AUTOSENSE and then is
issuing a REQUEST_SENSE command to get the sense data manually after a
check condition. Unfortunately when this happens the data returned (in
the data, not the sense buffer) doesn''t have the correct information -
it should contain details of the check condition but is mostly blank
apart from a length field. When the end of a SCSI tape ''file''
is
reached, a check condition occurs with a ''Filemark detected''
flag set,
so Backup Exec would know that the error is just that we reached the end
of the file. Because we are returning incorrect data in response to a
REQUEST_SENSE operation, Backup Exec assumes that there is a real error
and fails.
I don''t know enough about SCSI in general and Linux SCSI in particular
to be sure about this, but I suspect that maybe pvSCSI is asking for
autosense, and so the SCSI device is clearing it''s check condition (and
the sense data), but Windows doesn''t want the sense data.
Can anyone comment on my assumption about the operation of SCSI? If
correct, I think we need a flag (VSCSIIF_ACT_SCSI_NO_SENSE perhaps) that
can be set with VSCSIIF_ACT_SCSI_CDB to indicate that autosense should
not be performed...
Thanks
James
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel