From: Markus Waldorf (waldorfm@rferl.org)
Date: Mon Jan 13 2003 - 09:36:14 EST
Thanks a lot to everyone who responded so far, in particular to Johan
Brusche and Dr. Thomas Blinn.
So far there is no explanation for the ID:21 <null> device accompanied by
the DLT-4000 drive, but using the commands below was enough to get the tape
going.
The commands I used were:
hwmgr -delete component -id 21
21: 3 merlin tape none 0 1 (null)
23: 4 merlin tape none 0 2 tape1 [1/3/0]
.. but then the drive appeared again as ID:0. BTW: The ID in the 2nd column
is a "logical id" not the scsi target id.
# hwmgr -scan scsi
# hwmgr -refresh scsi
# hwmgr -show scsi
0: 3 merlin tape none 0 1 (null)
18: 0 merlin disk none 2 1 dsk0 [0/1/0]
19: 1 merlin disk none 0 1 dsk1 [0/2/0]
20: 2 merlin cdrom none 0 1 cdrom0 [0/5/0]
23: 4 merlin tape none 0 2 tape1 [1/3/0]
and "dsfmgr -m tape1 tape0"
to get my tape0 back. Now I can use e.g. "mt rewind".
Also, very interesting commands and readings were:
---------------------------------------------------------------------------
# hwmgr -sho scsi -id 23 -full
23: 4 merlin tape none 0 2 tape1 [1/3/0]
WWID:04100022:"Quantum DLT4000 CX741M6206"
BUS TARGET LUN PATH STATE
------------------------------
>>> 1 4 0 stale
1 3 0 valid
The stale path tells you that the same drive serial number was seen
at one time on the system with SCSI target-id #4. Normally you should be
able to clear the stale path with the command
"hwmgr refresh scsi"
---------------------------------------------------------------------------
# hwmgr view device
4: /dev/kevm
18: /dev/disk/dsk0c IBM DNES-309170 bus-0-targ-1-lun-0
19: /dev/disk/dsk1c IBM DNES-309170 bus-0-targ-2-lun-0
20: /dev/disk/cdrom0c SONY CD-R CDU920S bus-0-targ-5-lun-0
23: /dev/ntape/tape1 Quantum DLT4000 bus-1-targ-3-lun-0
---------------------------------------------------------------------------
Deleting a previously detected entry.
# hwmgr -delete component -id 21
hwmgr: Delete operation was successful
# hwmgr -show scsi
0: 3 merlin tape none 0 1 (null)
18: 0 merlin disk none 2 1 dsk0 [0/1/0]
19: 1 merlin disk none 0 1 dsk1 [0/2/0]
20: 2 merlin cdrom none 0 1 cdrom0 [0/5/0]
23: 4 merlin tape none 0 2 tape1 [1/3/0]
But, now it shows up at HWID:0. .... 8-(
---------------------------------------------------------------------------
The "file" command shows device characteristics:
# file /dev/ntape/tape0
/dev/ntape/tape0: character special (19/70) SCSI #1 "DLT4000" tape #4
(SCSI ID #0) (SCSI LUN #4) errors = 0/1 81630_bpi
---------------------------------------------------------------------------
There is device information in /etc/ddr.dbase (text format).
---------------------------------------------------------------------------
Original message:
Hello,
I'm trying to use an old single DLT 20/40 tape drive (APS not Digital) on an
old DEC 3000 M700 workstation. The device is properly terminated, does not
make any ID conflict and works fine when I boot into OpenVMS 7.2, but it has
trouble when booting into Tru64 v5.1 on the same machine (different HD). Are
there any specific requirements for the drive to be used under Unix?
Unfortunately the vendor does not have appropriate online information, I
cannot locate the manual anymore and did not find any useful info on the
net.
At the console:
>>> sho dev
...
...
MKB300 B/3/0 TAPE RM DLT-4000 CD5A
At the OS:
# hwmgr -show scsi
SCSI DEVICE DEVICE DRIVER NUM DEVICE FIRST
HWID: DEVICEID HOSTNAME TYPE SUBTYPE OWNER PATH FILE VALID PATH
-------------------------------------------------------------------------
18: 0 merlin disk none 2 1 dsk0 [0/1/0]
19: 1 merlin disk none 0 1 dsk1 [0/2/0]
20: 2 merlin cdrom none 0 1 cdrom0 [0/5/0]
21: 3 merlin tape none 0 1 (null)
23: 4 merlin tape none 0 2 tape1 [1/3/0]
As you can see, the tape uses ID 3, but the system somehow involves ID 4.
It seems like other devices look strange too, e.g. cdrom real ID 5, but
Tru64 ID 2, or is it just listing in numerical order? Anyway, no problems
under OpenVMS on the same computer. I cannot use the tape drive under Tru64
(tried all tape device files), Error: no such device or address. Any ideas?
Best regards,
Markus Waldorf
RFE/RL, Inc.
www.rferl.org
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:03 EDT