The current Windows hosts don't handle the ATA_16 command and furthermore return a generic error code after filtering the command on the host side. For now filter the command on the guest side until the host is modified to properly handle unsupported commands. I would like to thank Jeff Garzik <jgpobox@xxxxxxxxx> and Douglas Gilbert <dgilbert@xxxxxxxxxxxx> for suggesting the correct approach here. Signed-off-by: K. Y. Srinivasan <kys@xxxxxxxxxxxxx> Reviewed-by: Haiyang Zhang <haiyangz@xxxxxxxxxxxxx> --- drivers/scsi/storvsc_drv.c | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index d5448e8..e9e37dd 100644 --- a/drivers/scsi/storvsc_drv.c +++ b/drivers/scsi/storvsc_drv.c @@ -1233,9 +1233,21 @@ static bool storvsc_scsi_cmd_ok(struct scsi_cmnd *scmnd) /* * smartd sends this command and the host does not handle * this. So, don't send it. + * The current Windows hosts implement a subset of scsi commands + * and for the commands that are not implemented, the host filters + * them and returns a generic failure SRB status. I have been in + * discussions with the Windows team to return the appropriate SRB + * status code for unsupported scsi commands and while they have + * agreed to implement this, it is not clear when this change will be + * available. Consequently, filtering the command before submitting it + * to the host is a resonable interim solution. */ case SET_WINDOW: - scmnd->result = ILLEGAL_REQUEST << 16; + case ATA_16: + scmnd->result = ((DRIVER_SENSE << 24) | + SAM_STAT_CHECK_CONDITION); + scsi_build_sense_buffer(0, scmnd->sense_buffer, + ILLEGAL_REQUEST, 0x20, 0); allowed = false; break; default: -- 1.7.4.1 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
