SCSI ReadCapacity16 is failing in windows driver for BOT mode with CheckCondition and Invalid Opcode

WINDBG
1

I have two USB drives.

  1. Drive_1 - It supports USB SCSI protocol in BOT mode only. I see below observations for SCSI ReadCapacity16 command execution in Drive_1.
    a. USB SCSI ReadCapacity16 command works properly in windows driver for BOT mode. The command request and response are captured in Wireshark traces.
    b. USB SCSI ReadCapacity16 command works properly with inhouse developed driver for BOT mode. The command request and response are captured in Wireshark traces.

  2. Drive_2 - It supports USB SCSI protocol in both BOT and UAS mode. I see below observations for SCSI ReadCapacity16 command execution in Drive_2.
    a. USB SCSI ReadCapacity16 command is failing in windows driver for BOT mode with CheckCondition and Invalid Opcode error. Here I notice that the command request is not captured in Wireshark or Lecroy tools.
    b. USB SCSI ReadCapacity16 command works properly with inhouse developed driver for BOT mode. The command request and response are captured in Wireshark traces.
    c. USB SCSI ReadCapacity16 command works properly in windows driver for UAS mode. The command request and response are captured in Wireshark traces.
    d. USB SCSI ReadCapacity16 command works properly with inhouse developed driver for UAS mode. The command request and response are captured in Wireshark traces.

CDB details:
cdbLength = 16
serviceAction = 0x10
allocationLength = 32

cdb[0] = 0x9E //Opcode
cdb[1] = serviceAction
cdb[2] = 0
cdb[3] = 0
cdb[4] = 0
cdb[5] = 0
cdb[6] = 0
cdb[7] = 0
cdb[8] = 0
cdb[9] = 0
cdb[10] = (allocationLength >> 24) & 0xFF
cdb[11] = (allocationLength >> 16) & 0xFF
cdb[12] = (allocationLength >> 8) & 0xFF
cdb[13] = (allocationLength & 0xFF)
cdb[14] = 0
cdb[15] = 0

cdb = [0x9E 0x10 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x20 0x00 0x00]

Error raised for ReadCapacity16 command:
Sense Key Desc : Illegal Request (0x05)
Additional Error Desc : INVALID COMMAND OPERATION CODE
Additional Sense Code & Qualifier: 0x20 & 0x00

Sense Buffer :
[ 0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a ]
[ 0x00 0x00 0x00 0x00 0x20 0x00 0x00 0x00 ]
[ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ]
[ 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ]

I see that firmware supports ReadCapacity16 command and hence 2.b, 2.c and 2.d steps are successful above.

Any help would be appreciated to debug the failure for 2.a step above in Drive_2 with windows driver.

2

Does 2A failing really matter? Isn’t running the device in UAS mode the “right” thing to do?

3

Hi Scott,

There are some usecases to execute Write/Read commands by forcing the drive in BOT mode rather than UAS. So at the beginning of the test, executing ReadCapacity16 to fetch the MaxLBA supported by the drive.

Yes, failure in step 2.a does matter because there is firmware support for ReadCapacity16 command. But for some reason, I see INVALID_OPCODE_ERROR.

Can windows driver make a decision to report INVALID_OPCODE error to the host without sending the request to the device?

Thanks

4

@vkoninti said:

Can windows driver make a decision to report INVALID_OPCODE error to the host without sending the request to the device?

Absolutely.

ClassPnP builds and sends the SCSIOP_READ_CAPACITY command:

https://github.com/microsoft/Windows-driver-samples/blob/main/storage/class/classpnp/src/class.c#L2686

For a USB BOT (or CB/CBI) device it’s then going to go into USBSTOR who wraps it in USB and sends it. If you’re not seeing the command on a hardware USB analyzer then my guess is that USBSTOR is rejecting it for some reason…

I’d probably start by putting a breakpoint in classpnp!ClassReadDriveCapacity, single stepping, and seeing how things go. As you can see from the code normally you see the 10-byte version first and then the 16-byte version if necessary.