tape drive on tru64 5.1

[Julie Harold_1]

I can't figure out why my tape drives are not being seen ?

I have two tape changers, each with a single tape drive, both seen by scu

>scu show edt

CAM Equipment Device Table (EDT) Information:

Bus/Target/Lun Device Type ANSI Vendor ID Product ID Revision N/W
-------------- ----------- ------ --------- ---------------- -------- ---
0 0 0 Direct SCSI-2 COMPAQ BB00912301 B016 W
0 6 0 Sequential SCSI-3 ARCHIVE Python 06241-XXX 8160 W
0 6 1 Changer SCSI-3 ARCHIVE Python 06241-XXX 8160 W
1 0 0 CD-ROM SCSI-2 COMPAQ CD-224E 9.5B N
7 0 0 Direct SCSI-3 SEAGATE ST373405LW 0001 W
7 2 0 Direct SCSI-3 SEAGATE ST373405LW 0001 W
7 3 0 Direct SCSI-3 SEAGATE ST1181677LW 0001 W
7 5 0 Direct SCSI-3 SEAGATE ST1181677LW 0001 W
8 6 0 Sequential SCSI-3 SEAGATE DAT 06241-XXX 8110 N
8 6 1 Changer SCSI-3 SEAGATE DAT 06241-XXX 8110 N
9 3 0 Direct SCSI-3 SEAGATE ST373405LW 0001 W
9 5 0 Direct SCSI-3 SEAGATE ST373405LW 0001 W

however hwmgr -show scsi only see the changers

# hwmgr -show scsi

SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH
-------------------------------------------------------------------------
43: 0 iron disk none 2 1 dsk0 [0/0/0]
44: 1 iron cdrom none 0 1 cdrom0 [1/0/0]
46: 2 iron disk none 2 5 dsk1 [9/5/0]
47: 3 iron disk none 2 5 dsk2 [9/3/0]
59: 5 iron disk none 2 3 dsk3 [7/5/0]
60: 6 iron disk none 2 3 dsk4 [7/3/0]
61: 7 iron disk none 0 2 (null)
88: 4 iron changer none 0 8 mc0 [8/6/0]
93: 8 iron cdrom none 0 1 (null)
99: 9 iron changer none 0 2 mc1 [0/6/0]
100: 10 iron disk none 2 1 dsk6 [7/0/0]
101: 11 iron disk none 2 1 dsk7 [7/2/0]


do I need to add something to /etc/ddr.dbase ? If so what.

These drives were working on a system running v4.0 1091
# scu show edt

CAM Equipment Device Table (EDT) Information:

Device: RZ28D Bus: 0, Target: 0, Lun: 0, Type: Direct Access
Device: RRD46 Bus: 0, Target: 4, Lun: 0, Type: Read-Only Direct Access
Device: Python 06241-XXX Bus: 0, Target: 6, Lun: 0, Type: Sequential Access
Device: Python 06241-XXX Bus: 0, Target: 6, Lun: 1, Type: Medium Changer
Device: ST373405LW Bus: 1, Target: 0, Lun: 0, Type: Direct Access
Device: ST373405LW Bus: 1, Target: 2, Lun: 0, Type: Direct Access

where the tape was seen as /dev/nrmt0h

why is it not creating /dev/tape/tape0 etc ?

Thanks, Julie

[Peter Leddy_1]

Hi Julie,

HAve you done the following, if not try it, it should create the device files for the tape -

# /sbin/dn_setup -install_tape

You may see messages such as +tape0 that list the device names that are created during this operation. The plus sign indicates that the device is being added.

# hwmgr -view device

To check if the device files were created.

HTH,

Peter

[Julie Harold_1]

tried that. I get :

# /sbin/dn_setup -install_tape
(nothing seen on screen)

# hwmgr -view device
HWID: Device Name Mfg Model Location
------------------------------------------------------------------------------
3: /dev/scp_scsi
4: /dev/kevm
36: /dev/disk/floppy0c 3.5in floppy fdi0-unit-0
43: /dev/disk/dsk0c COMPAQ BB00912301 bus-0-targ-0-lun-0
44: /dev/disk/cdrom0c COMPAQ CD-224E bus-1-targ-0-lun-0
46: /dev/disk/dsk1c SEAGATE ST373405LW bus-9-targ-5-lun-0
47: /dev/disk/dsk2c SEAGATE ST373405LW bus-9-targ-3-lun-0
59: /dev/disk/dsk3c SEAGATE ST1181677LW bus-7-targ-5-lun-0
60: /dev/disk/dsk4c SEAGATE ST1181677LW bus-7-targ-3-lun-0
88: /dev/changer/mc0 DAT 06241-XXX bus-8-targ-6-lun-0
94: /dev/dmapi/dmapi
97: /dev/random
98: /dev/urandom
99: /dev/changer/mc1 Python 06241-XXX bus-0-targ-6-lun-0
100: /dev/disk/dsk6c SEAGATE ST373405LW bus-7-targ-0-lun-0
101: /dev/disk/dsk7c SEAGATE ST373405LW bus-7-targ-2-lun-0

[Uwe Zessin]

Julie,
it looks like the operating system cannot distinguish the tape drive (at LUN 0) from the changer (at LUN1). If you look at HWID:99 for example, you see that it claims to have two(2) paths to the changer.

[Julie Harold_1]

um - there are 2 changers (mc1 amd mc0) and each should have a tape associated with it. I know it has created /dev/tape/tape0 with a previous version of tru64 (5.0 maybe) - but I can't figure out why it won't now.

[Peter Leddy_1]

Julie,

Can you try the following

# hwmgr -scan scsi

Hopefully this will discover the tapes and create devices for them.

Peter

[Uwe Zessin]

Yes, look at HWID:88 (mc0) - that one reports even eight(8) paths! It looks like those devices do not respond properly to the SCSI enquiry.

Somehow the operating system cannot distingish the paths to the LUNs and believes it is always the same device behind the target ID.

[Julie Harold_1]

hwmgr -scan scsi makes no difference

It seems to be putting the tape device (lun 0) as the changer (mc0 and mc1) and then ignoring the changer on lun 1.

But how on earth do I get it to talk to me ?

incidentally before booting I get

>>> show device

jka601.6.0.7.1 Archive Python 06241-XXX 8160
jkb601.6.0.8.1 Seagate Dat 06241-XXX 8110
mka600.6.0.7.1 Archive Python 06241-XXX 8160
mkb600.6.0.8.1 Seagate Dat 06241-XXX 8110

[Michael Schulte zur Sur]

Hi,

could you please post:
ls -l /devices/changer
file /devices/changer/*
mt -f /devices/changer/mc0 status
mt -f /devices/changer/mc1 status

thanks,

Michael

[Julie Harold_1]

ok - here goes.

# ls -l /devices/changer
total 0
crw-rw-rw- 1 root system 19,202 May 13 13:34 mc0
crw-rw-rw- 1 root system 19,203 May 13 13:34 mc1
# file /devices/changer/*
/devices/changer/mc0: character special (19/202) SCSI #0 "Python 0" special_device #0 (SCSI ID #6) (SCSI LUN #0)
/devices/changer/mc1: character special (19/203) SCSI #8 "DAT 0" special_device #0 (SCSI ID #6) (SCSI LUN #0)
# mt -f /devices/changer/mc0 status

DEVIOGET ELEMENT CONTENTS
---------------- --------
category DEV_SPECIAL
bus DEV_SCSI
interface SCSI
device Python 0
adpt_num 0
nexus_num 7
bus_num 0
ctlr_num 0
slave_num 0
dev_name mc
unit_num 4
soft_count 0
hard_count 0
stat 0x0

category_stat 0x0


DEVGETINFO ELEMENT CONTENTS
------------------ --------
media_status 0x0

unit_status 0x0
Offline 2_FM_Close NO_Rewind
record_size 0
density (current) 0 BPI
density (on write) 0 BPI
Filemark Cnt
Record Cnt
Class 0 -
mtiocget ioctl failed!


# mt -f /devices/changer/mc1 status

DEVIOGET ELEMENT CONTENTS
---------------- --------
category DEV_SPECIAL
bus DEV_SCSI
interface SCSI
device DAT 0
adpt_num 0
nexus_num 8
bus_num 2
ctlr_num 8
slave_num 0
dev_name mc
unit_num 7
soft_count 0
hard_count 0
stat 0x0

category_stat 0x0


DEVGETINFO ELEMENT CONTENTS
------------------ --------
media_status 0x0

unit_status 0x0
Offline 2_FM_Close NO_Rewind
record_size 0
density (current) 0 BPI
density (on write) 0 BPI
Filemark Cnt
Record Cnt
Class 0 -

mtiocget ioctl failed!

[Ralf Puchner]

be sure you configured the hardware properly not mixing changer and tapes on same bus.

[Julie Harold_1]

the changer is an external unit - it has the tape drive within it. Each changer/tape unit is on it's own scsi chain.

My understanding from the console and scu show edt is that the changer is lun1 and the tape drive is lun 0

>scu show edt
0 6 0 Sequential SCSI-3 ARCHIVE Python 06241-XXX 8160 W
0 6 1 Changer SCSI-3 ARCHIVE Python 06241-XXX 8160 W
8 6 0 Sequential SCSI-3 SEAGATE DAT 06241-XXX 8110 N
8 6 1 Changer SCSI-3 SEAGATE DAT 06241-XXX 8110 N

how come scu can see it but hwmgr can't ?

[Julie Harold_1]

I have just found this on another thread

# hwmgr view d
HWID: Device Name Mfg Model Location
------------------------------------------------------------------------------



226: /dev/ntape/tape4 COMPAQ SDLT320 bus-1-targ-0-lun-2
227: /dev/changer/mc2 MSL5000 Series bus-1-targ-0-lun-0
228: /dev/ntape/tape5 COMPAQ SDLT320 bus-1-targ-0-lun-1

so they are managing to see the other luns - what am I missing ?

[Uwe Zessin]

Julie,
what is the output of
# hwmgr -show scsi -did 9 -full

please try to post it as a .TXT attachment. If you simply paste it in the message box all spaces are collapsed.

--

I beleive there is a problem with the reporting of these devices. They look the same to Tru64 Unix Version 5, so it beleives LUNs 0 and 1 are just different paths to the same device.

[Julie Harold_1]

that gives me nothing at all

is this - more use (bus 8)

[Uwe Zessin]

Interesting...

Anyway, the last output clearly shows that the operating system beleives that bus:target:lun 8:6:0 and 8:6:1 refer to the same device. It somehow cannot tell them apart.

[Julie Harold_1]

I have just done a sys_check and it clearly shows that scu can tell them apart but the hwmgr can't. Where do I go from here ?

[Julie Harold_2]

I really only need the drive for tar and dump - so I can do without the changer bit. Is there some way I can either use the changer to do tar and dump, or alternatively tell the system to ignore the changer and map the drive only ?

[Ralf Puchner]

Please check if cabling is ok, which means there are some limitations regarding changer/tape mix on same bus.

Verify the named tape/changer is supported with the OS-version and ddr database contains valid entries for the tape/changer.
(see http://ftp.support.veritas.com/pub/support/products/NetBackup_DataCenter/255216.pdf - Tru64 5.x config - for information which entries are necessary)

Next be sure you installed the latest patchkit, e.g. a problem in 5.1A pk 3 leads to similar problem.

If using only the tape drives, unplug the changer and delete the device within Tru64 (hwmgr/dsfmgr - have a look into the admin guide explaining syntax and command)

[Yong_7]

Julie,

here is my plan for your reference.
the idea is put the pieces on one by one.


1. if applicable, apply the latest patch kit
2. "hwmgr -delete" to remove the changer AND tape.
3. disconnect changer and keep tape connected.
4. /sbin/dn-setup -install_tape
5. is tape working fine ? ( i bet it's working )
6. ( hwmgr -delete ) remove tape and disconnect
7. connect changer.
8. do same to create device name
9. does changer work ?
(assuming you connect HW to where they used to be )if it works, confilict between changer and tape due to bus # ? low quality cable ? whatever ?

if it won't work. compatibilities ?

just thoughts.

Good Luck!

[Ralf Puchner]

it is not a hw-database problem, I've seen this on other customers machine. Cabling, patchkit or ddr database issue...

[Orrin]

HI Julie,

We had similar issues, and as it turned out the firmware on the Tape Library and the Tape drives needed upgrading.

We have a tape library connected to a VMS cluster and a Unix Cluster. The tape device could not be seen on the VMS cluster and the UNix cluster. After confirming the zoning etc, we kept losing connection to the library and the tape device was not available.

The reason I'm not sure is we used the COMpaq Tape l;ibraries and you are using The Seagate Library, well you may have to investigate further. Hope this helps.

Regards,
Orrin.

[Julie Harold_1]

thanks everyone - I will try updating the patch kit and sorting out the firmware on the tape, then I will have a go at disconnecting the changer and see what happens.

I will report back - probably in a few days.

Julie

[Julie Harold_1]

update - I have put the latest patches on (T64V51BB24AS0003-20030929.tar) and it made no difference. I am now talking to the suppliers to try and get firmware updates and check the setting for /etc/ddr.dbase.

Failing that I will have to try disconnecting the changer - last option because the machine is operational and users are reluctant to let me turn it off !

Julie

[Julie Harold_1]

do I need to add anything to /etc/mcicap ? If so what ?

thanks, Julie