Lots of scary looking errors from SCST like:
Sep 7 00:56:48 centos6vtl kernel: : scst_check_unblock_dev:160:cmd c6122e90 (tag 788529152): unblocking dev 3:1:0:2
Sep 7 00:56:48 centos6vtl kernel: : scst_unblock_dev:6596:Device UNBLOCK(new 0), dev 3:1:0:2
Sep 7 00:56:48 centos6vtl kernel: : __scst_check_blocked_dev:6569:cmd c6122e90 (tag 805306368, op 5e): blocking further cmds on dev 3:1:0:2 due to serialized cmd
Sep 7 00:56:48 centos6vtl kernel: : scst_block_dev:6519:Device BLOCK (new count 1), dev 3:1:0:2
Sep 7 00:56:48 centos6vtl kernel: : scst: scst_persistent_reserve_in_local:2079:***WARNING***: PR commands for pass-through devices not supported (device 3:1:0:2)
Sep 7 00:56:48 centos6vtl kernel: : scst_check_unblock_dev:160:cmd c6122e90 (tag 805306368): unblocking dev 3:1:0:2
But I think these are informational..
The only "error" I can see is an attempt to query mode page 25h
Sep 7 00:56:32 centos6vtl vtltape: CDB (159) 5a 00 25 00 00 00 00 00 30 00
Sep 7 00:56:32 centos6vtl vtltape: spc_mode_sense: MODE SENSE (159) **
Sep 7 00:56:32 centos6vtl vtltape: mkSenseBuf: SENSE [Key/ASC/ASCQ] [05 24 00]
I can't find this referenced in my IBM LTO (11th edition) SCSI Reference Guide.
The SSC4 defines mode pages between 20h - 3Eh as 'Vendor Specific' - So no luck there either.
The earlier attempt to get to mode page 24h was successful:
Sep 7 00:56:32 centos6vtl vtltape: CDB (158) 5a 00 24 00 00 00 00 00 28 00
Sep 7 00:56:32 centos6vtl vtltape: spc_mode_sense: MODE SENSE (158) **
FWIW: The initiator is suppose to issue a 'list supported mode pages', and then send queries if the target supports the mode page in question. I see no request for mode page '3f' (list supported mode pages).
I'm thinking that this is a driver issue on the Windows side of the world. Perhaps the driver is failing because it can't get this mode page (improbable), or the LTO tape driver is not correct.
I do know the Windows drivers and NetBackup results in lots of heartache. Hence why I've gone the STK / T10000B drive config. Windows is able to automagically install a working driver. The SDLT / LTO drivers seem to be such fragile things on Windows.
Another check is to setup iSCSI initiator on a Linux host and test TSM access to this 'centos6vtl' host. i.e. Rule out Windows tape drivers as being the cause.
Or install the sg3_utils on Windows and check device connectivity using the sg3 utilities (sg_turs, sg_inq, sg_logs, sg_modes etc)
OK, having a better look at this, I realise I've got a broken 'MODE SELECT' implementation.
Byte 1 of the MODE PARAMETER HEADER should indicate the Media Type (LTO-1 data / LTO-4 WORM etc)..
I fail to set this at all. The value of '0' indicates no mounted media - The current behaviour..
While I do have a 'media type' field set in the MAM of each media, it is mhvtl unique code and does not match hardware vendor's code(s).
So, I have two options here.
1. Break media compatibility and update the mhvtl media_type to match hardware vendors values (Hopefully I can find all relevant documentation).
2. Keep my unique 'media_type' and have a lookup table between mhvtl media_type -> vendor's media_type.
Option 2 is most likely the way I'll go. It requires more code but I don't need to find all correct values on the first go. (i.e. I can always have a media_type == VENDOR_media_type_unknown value).
What version of tape drivers are being used ?
Is there any difference if HP LTO4 is configured (i.e. Different Windows tape drivers)..
Has LTO2 or LTO3 been tried and does that also fail the same way ?