Benchmark VS640 autochanger

[david rabjohns_1]

Can't seem to get the above device to work with TRU645.1B.

HBA Card supports multiple luns and can see both luns on the SCSI bus. (see below)

2 0 0 Sequential SCSI-2 BNCHMARK VS640 5032 W

2 0 1 Changer SCSI-2 BNCHMARK VS640 5032 W

The OS can see the devices on the SCSI bus, but does not create a tape device (i.e. /dev/tape/tape0c). The changer device is created however (/dev/changer/mc0)

Any ideas ?

Regards

Dave

[Johan Brusche]

? What do you get from :

hwmgr sho scsi -id nn -full
or
hwmgr get attrib -id nn

Else try:

/sbin/scu
scu > sbtl x y z (bus# target# lun#)
scu > sow dev

Didn't the vendor "Benchmark" provide a ddr.dbase entry for this device ?

__ Johan.

[david rabjohns_1]

Thanks for the response..(have changed the SCSI ID of the device from 0 to 1)

> hwmgr sho scsi -id 92 -full

SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH
-------------------------------------------------------------------------
92: 6 IS12 changer none 0 2 mc0 [2/1/0]

WWID:04100022:"BNCHMARKVS640 PHD2D06432"


BUS TARGET LUN PATH STATE
------------------------------
2 1 0 valid
2 1 1 valid



=========================================

92:
name = SCSI-WWID:04100022:"BNCHMARKVS640 PHD2D06432"
category = media_changer
architecture = SCSI
phys_location = bus-2-targ-1-lun-0
dev_base_name = mc0
model = VS640
registration_time = Mon Jan 24 16:42:27 2005
user_name = (null) (settable)
location = (null) (settable)
software_module = (null)
state = available
state_previous = unknown
state_change_time = none
event_count = 1
last_event_time = Mon Jan 24 16:42:30 2005
access_state = online
access_state_change_time = none
capabilities = 0
indicted = 0
indicted_probability = (null)
indicted_urgency = (null)
disabled = 0
firmware_rev = 5032
resid = 0
sense_info = 0
sense_key = 0
soft_err = 0
hard_err = 0
active_paths = 1
standby_paths = 1
failed_paths = 0
donot_use_paths = 0
path_fail_limit = 1
subsys_dev_handle = 6
consistent_name = 1
ccmn_specific_addr = 18446739677723402240
cluster_dev_directions = 0 (settable)
drvr_max_xfer = 16777215
path_port_id_2 = 2
path_target_id_2 = 1
path_lun_id_2 = 0
path_dev_i/o_cnt_2 = 0
path_state_2 = 1
path_new_state_2 = 0
path_xfer_2 = 0
path_wds_2 = 0
path_avserv_2 = 0
path_pxfer_2 = 0
path_avwait_2 = 0
path_port_id_2 = 2
path_target_id_2 = 1
path_lun_id_2 = 1
path_dev_i/o_cnt_2 = 0
path_state_2 = 2
path_new_state_2 = 0
path_xfer_2 = 0
path_wds_2 = 0
path_avserv_2 = 0
path_pxfer_2 = 0
path_avwait_2 = 0
name = SCSI-WWID:04100022:"BNCHMARKVS640 PHD2D06432"
category = media_changer
architecture = SCSI
phys_location = bus-2-targ-1-lun-1
dev_base_name = (null)
model = VS640
firmware_rev = 5032
resid = 0
sense_info = 0
sense_key = 0
soft_err = 0
hard_err = 0
active_paths = 1
standby_paths = 1
failed_paths = 0
donot_use_paths = 0
path_fail_limit = 1
subsys_dev_handle = 6
consistent_name = 1
ccmn_specific_addr = 18446739677723402240
cluster_dev_directions = 0 (settable)
drvr_max_xfer = 16777215
path_port_id_2 = 2
path_target_id_2 = 1
path_lun_id_2 = 0
path_dev_i/o_cnt_2 = 0
path_state_2 = 1
path_new_state_2 = 0
path_xfer_2 = 0
path_wds_2 = 0
path_avserv_2 = 0
path_pxfer_2 = 0
path_avwait_2 = 0
path_port_id_2 = 2
path_target_id_2 = 1
path_lun_id_2 = 1
path_dev_i/o_cnt_2 = 0
path_state_2 = 2
path_new_state_2 = 0
path_xfer_2 = 0
path_wds_2 = 0
path_avserv_2 = 0
path_pxfer_2 = 0
path_avwait_2 = 0

sbtl 2 1 1
Device: VS640, Bus: 2, Target: 1, Lun: 1, Type: Medium Changer
scu> sho dev

Inquiry Information:

SCSI Bus ID: 2
SCSI Target ID: 1
SCSI Target LUN: 1
Peripheral Device Type: 0x8 (Medium Changer)
Peripheral Qualifier: 0 (Peripheral Device Connected)
Device Type Modifier: 0
Removable Media: Yes
ANSI Version: 2 (Complies to ANSI X3.131-1994, SCSI-2)
ECMA Version: 0
ISO Version: 0
Response Data Format: 2 (SCSI-2)
Terminate I/O Process: No
Additional Length: 51
Soft Reset Support: No
Command Queuing Support: No
Target Transfer Disable: No
Linked Command Support: Yes
Synchronous Data Transfers: Yes
Support for 16 Bit Transfers: Yes
Support for 32 Bit Transfers: No
Relative Addressing Support: No
Vendor Identification: BNCHMARK
Product Identification: VS640
Firmware Revision Level: 5032

Device: VS640, Bus: 2, Target: 1, Lun: 0, Type: Sequential Access
scu> show dev

Inquiry Information:

SCSI Bus ID: 2
SCSI Target ID: 1
SCSI Target LUN: 0
Peripheral Device Type: 0x1 (Sequential Access)
Peripheral Qualifier: 0 (Peripheral Device Connected)
Device Type Modifier: 0
Removable Media: Yes
ANSI Version: 2 (Complies to ANSI X3.131-1994, SCSI-2)
ECMA Version: 0
ISO Version: 0
Response Data Format: 2 (SCSI-2)
Terminate I/O Process: No
Additional Length: 51
Soft Reset Support: No
Command Queuing Support: No
Target Transfer Disable: No
Linked Command Support: Yes
Synchronous Data Transfers: Yes
Support for 16 Bit Transfers: Yes
Support for 32 Bit Transfers: No
Relative Addressing Support: No
Vendor Identification: BNCHMARK
Product Identification: VS640
Firmware Revision Level: 5032


Everything appears as it should be (in scu). I have found another error message from the boot log

hwc_check_category: Member SCSI-WWID:04100022:"BNCHMARKVS640 PHD2D06432" is already in Category media_changer request to register with Category tape rejected

I can see that in scu the media changer is on lun 1 and the tape on lun 0. However hwmgr thinks the media changer is on lun 0 and fails to create the tape device - hence the error above.

No ddr.dbase entry for this device unfortunately.

help !

[Johan Brusche · Accepted solution]

The problem with this VS640 combo is that it presents the same wwid to the OS for both devices. Therefore the OS decides these are 2 paths to the same device.

The hardware device is responsible for providing a unique identifier to the V5 operating system. If the hardware does not provide such a unique identifier, the O/S will generate a unique identifier based on the devices scsi address.
There are however, several devices that use the same unique identifier for all their logical units (so much for uniqueness). Most often, these devices are raid controllers where the unique value is the serial number of the controller itself. Since all the logical units are serviced by the same hardware controller, they report the same serial number. This however, causes the V5 operating system to assume they are in fact the same data set simply available at different paths (different targets and/or luns). This can be seen in the output of the hwmgr command:


# hwmgr -show scsi -did 9 -full

SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH
-------------------------------------------------------------------------
88: 9 fudge disk none 0 4 dsk12 [3/0/0]

WWID:04100028:"IFT 3102 002F101X"

BUS TARGET LUN PATH STATE
------------------------------
3 0 0 valid
3 1 0 valid
3 2 0 valid
3 3 0 valid
#

All 4 of these luns are different, but since they all report the serial number of "002F101X" they are viewed by the O/S as the same device (just with 4 different paths).
To solve this problem, the ddr.dbase file allows the system manager to tell the O/S to add its own unique identifier (such as the address) to that which is supplied by the hardware. This operation is 100% safe only for those interconnects where the address is fixed (such as parallel scsi). This ddr.dbase entry would look as follows:


#
# Option to add d/t/l to existing serial number
# This entry is for the IFT 3102 parallel scsi device.
# This works fine on parallel scsi.
#
SCSIDEVICE
#
Type = disk
Name = "IFT" "3102"
#
ATTRIBUTE:
AttributeName = "VPDinfo"
Length = 16
ubyte[5] = 11


#
# Option to add d/t/l to existing serial number
# This entry is for the XXX RAID Controller Fibre Channel device.
# This is not the recommended method for Fibre Channel devices.
#
SCSIDEVICE
#
Type = disk
Stype = 2
Name = "RAID" "Controller"
#
ATTRIBUTE:
AttributeName = "VPDinfo"
Length = 16
ubyte[5] = 11


Please, lean onto "Benchmark" to make their device compliant.

__ Johan.

[Johan Brusche]

Dave.
Benchmark has been acquired by QANTUM, and they call the VS640 the "ATL Value Loader".
So you will have to knock on Qantum's door for support.

__ Johan.

[david rabjohns_1]

Thanks Johan

That seems to have fixed it. It all comes flooding back, I remember having a similar problem with an Infortrend raid array - the device you cited I think. Dr Blinn pointed me in the right direction.

I tried to contact Quantum technical support before posting here. But the response was very slow, and did not offer any sort of solution.

[david rabjohns_1]

For info the following entries got this device to work.

Mcicap:

mc0|VS640|Benchmark VS640:\
:it=scsi2:dt=tape:ae:bc:vt:is:ls:pa:re:rs:sv:\
:dn=/dev/tape/tape0c:mc=/dev/changer/mc0:

Ddr.dbase

Tape entry:
SCSIDEVICE
#
# Matches DLT8000
#
#
Type = tape
Name = "BNCHMARK" "VS640"
# with DLT entries 4 and 5
#
PARAMETERS:
TypeSubClass = tk
TagQueueDepth = 0
MaxTransferSize = 0x0ffffff # (16MB - 1)
ReadyTimeSeconds = 120 # seconds

DENSITY:
#
DensityNumber = 0
DensityCode = 0x1b
CompressionCode = 0x1
Buffered = 0x1

DENSITY:
#
DensityNumber = 1
DensityCode = default
CompressionCode = 0x1
Buffered = 0x1

DENSITY:
#
DensityNumber = 2,6,7
DensityCode = default
CompressionCode = 0x0
Buffered = 0x1

DENSITY:
#
DensityNumber = 3
DensityCode = 0x1b
CompressionCode = 0x0
Buffered = 0x1

DENSITY:
#
DensityNumber = 4
DensityCode = 0x1a
CompressionCode = 0x0
Buffered = 0x1

DENSITY:
#
DensityNumber = 5
DensityCode = 0x1a
CompressionCode = 0x1
Buffered = 0x1

ATTRIBUTE:
#
AttributeName = "VPDinfo"
Length = 16
ubyte[5] = 11

changer entry:
SCSIDEVICE
#
#
Type = changer
Name = "BNCHMARK" "VS640"
#
PARAMETERS:
DisperseQueue = false
TagQueueDepth = 0x0
ATTRIBUTE:
AttributeName = "VPDinfo"
Length = 16
ubyte[5] = 11

[david rabjohns_1]

See previous reply