If SANITIZE is supported but we dont have the BlockDeviceCharacteristics
page we produce a warning.
If OVERWRITE is supported on SSDs we warn.
If BLOCK ERASE is supported on HDDs we warn.
order byte of the two byte transfer length field or not.
Since the maximum size of a std vpd page takes 260 bytes to transfer
and some targets send this much, testing and comparing the returned buffer
between allocation length == 255 and == 256 doesnt work.
Instead change test to verify that allocation length 511 and 512 returns the same amount and content of data.
This test then still allows finding targets that only look at the low order byte
(which is 0xff for 511 but is 0 for 512)
The tests currently verify whether two block limits are above 2**20. Change
these tests into <= 2**20.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
This is the maximum possible size of this page.
Previouslly we only read the arbitrary 255 bytes of page, but for targets
that return >255 bytes of data this would then incorrectly make the test fail
since the data-in buffer was truncated and thus the inq->additional_length
no longer matched up with the datain buffer size.
Now reading up to 260 bytes will avoid the datain buffer from ever becomming truncated, and as a second feature also make sure to test that the target
understands > 8-bit values for the allocation length in the request.
REPORT SUPPORTED OPCODES.
Opcodes that are listed in the full list of all supported opcodes as taking
a service action should work to ask reporting option 2 (uses service action)
from but fail when asked for option 1 (no service action)
Similarly, opcodes that are flagged as not taking a service action should
work when used with option 1 but fail with option 2.
Add a simple test that it works or is not implemented.
Add a RCTD test to verify that with this flag clear we get command descriptors without CTDP set and with it set we get command descriptors with CTDP set and a timeout descriptor
If BLockLimits->MaxWriteSameLength is 0 (no limit) or >=256
then verify that both WRITESAME10 and WRITESAME16 can unmap with a
number of blocks == 2 byte field.
If not, then verify that a 256 block unmap results in INVALID FIELD IN CDB
If BLockLimits->MaxWriteSameLength is 0 (no limit) or >=65536
then verify that WRITESAME16 can unmap with a
number of blocks == 3 byte field.
If not, then verify that a 65536 block unmap results in INVALID FIELD IN CDB
From discussions on linux-scsi there are devices that support WRITESAME16
but where the implementation only looks at the low 2 bytes of the 4 bytes for
num-blocks in the CDB.
This added test aims to find and flag such devices.
Discussions on linux-scsi indicate that some SBC-2 devices may provide
some SBC-3 features and thus a SBC-3 BlockLimit page.
Supporting more than you claim is a transgression but a relatively minor
one, so lets turn a blind eye to it.
Supporting less than you claim is a serious transgression and will always
result in a harsh test failure.
If the device does not support PI (INQ->PROTECT) then
verify that PROT_EN, P_TYPE and P_I_EXP are all zero.
If the device does support PI and IF PROT_EN is clear
then verify that both P_TYPE and P_I_EXP are zero.
If the device does support PI and IF PROT_EN is set
then verify that P_TYPE is 0, 1 or 2
Verify that the page length matches up with the size of the data in buffer.
Verify that page length is 0x3c if the device claims SBC-3, and 0x0c if not.
If the device claims SBC-3 and if it claims UNMAP support (LBPU)
then we check that both MAXIMUM UNMAP LBA COUNT and
MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT looks sane.
Sane here means >0, <1M or 0xffffffff
If the device claims SBC-3 and if it does not claim UNMAP support (LBPU)
then we check that both MAXIMUM UNMAP LBA COUNT and
MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT are both 0.
