SEO

I am trying to configure an external SCSI DAT drive to an Ultra60 w/
Solaris 9. It is a Dell Powervault 100T, which I find to be a
re-branded Seagate STD6401LW.

I Google'd the config details I would need for the /kernel/drv/st.conf
entry and found:

tape-config-list=
"SEAGATE DAT 06240-XXX", "Seagate DAT Drive", "SEAGATE_DAT";
SEAGATE_DAT = 1,0x34,0,0xd639,4,0x00,0x8C,0x8C,0x8C,3;

Following a handful of usenet posts I found, I placed that detail into
st.conf, rebooted, used STOP-A, and at OK prompt used:

setenv auto-boot? false
reset
probe-scsi-all

Solaris gave:
-------------------
/pci@1f, 4000/scsi@3,1
Target 4
Unit 0 Removable Tape Archive Python 06408-xxx8071

/pci@1f, 4000.scsi@3
Target 0
Unit 0 Disk Seagate <my 1st hard disk info....>

Target 1
Unit 0 Disk Seagate <my 2nd hard disk info....>

Target 6
Unit 0 Sony CD-Rom <etc...>
-------------------

I was happy to see something recognized, but I suppose I was a little
suprised to see it listing "Python" rather than a Seagate device.
Nonetheless I carried on with:

setenv auto-boot? true
boot -r

I noticed a handful of entries in /dev/rmt/. I attempted writing to the
drive with:
tar cvf /dev/rmt/0 /export/home/my_name/test/*

and got back: tar: /dev/rmt/0: I/O error

Having a look in /var/adm/messages I see:
Sep 19 11:38:36 sunking scsi: [ID 365881 kern.info]
/pci@1f,4000/scsi@3,1/st@4,0 (st11):
Sep 19 11:38:36 sunking <Archive Python 4mm Helical Scan>
Sep 19 11:38:36 sunking scsi: [ID 193665 kern.info] st11 at glm1: target
4 lun 0
Sep 19 11:38:36 sunking genunix: [ID 936769 kern.info] st11 is
/pci@1f,4000/scsi@3,1/st@4,0

So, do you think the details above are pointing me at having the wrong
config lines in my st.conf? Or, are the details from probe-scsi-all
suggesting I am stepping on the same SCSI id? I have the switch on the
back of the DAT drive set to "4"...I don't know if the scsi@3 part in
the probe-scsi-all results is significant to my problem.

Thanks for any pointers.
Rob

Robert Mazur <no-one@no-domain.com> wrote:
> I am trying to configure an external SCSI DAT drive to an Ultra60 w/
> Solaris 9. It is a Dell Powervault 100T, which I find to be a
> re-branded Seagate STD6401LW.
>
[snip]

> I was happy to see something recognized, but I suppose I was a little
> suprised to see it listing "Python" rather than a Seagate device.

[snip]

That seems quite likely. Archive Python and Seagate have been
interchangeable names for these things form many years, I think usually
depending on the flavour of the firmware in the drive.

The SCSI id could well be the problem. Pull off the connector to the
switch and use a couple of jumpers. Some devices have the bit order
reversed from others, so you switch may well be dialling up the wrong
number.


--
Dr Tristram J. Scott
Energy Consultant

Tristram Scott wrote:
> Robert Mazur <no-one@no-domain.com> wrote:
>
>>I am trying to configure an external SCSI DAT drive to an Ultra60 w/
>>Solaris 9. It is a Dell Powervault 100T, which I find to be a
>>re-branded Seagate STD6401LW.
>>
>
> [snip]
>
>
>>I was happy to see something recognized, but I suppose I was a little
>>suprised to see it listing "Python" rather than a Seagate device.
>
>
> [snip]
>
> That seems quite likely. Archive Python and Seagate have been
> interchangeable names for these things form many years, I think usually
> depending on the flavour of the firmware in the drive.
>
> The SCSI id could well be the problem. Pull off the connector to the
> switch and use a couple of jumpers. Some devices have the bit order
> reversed from others, so you switch may well be dialling up the wrong
> number.
>
>

Thanks for the note.

When attempting to write to the drive and getting "I/O error" as a
result, I am getting out of /var/adm/messages:

Sep 20 06:57:12 sunking scsi: [ID 365881 kern.info]
/pci@1f,4000/scsi@3,1/st@4,0 (st11):
Sep 20 06:57:12 sunking <Archive Python 4mm Helical Scan>
Sep 20 06:57:12 sunking scsi: [ID 193665 kern.info] st11 at glm1:
target 4 lun 0
Sep 20 06:57:12 sunking genunix: [ID 936769 kern.info] st11 is
/pci@1f,4000/scsi@3,1/st@4,0

I am guessing here, but it looks like Solaris is recognizing my DAT
drive at scsi id 4, with the piece that says "st@4". Am i right? Of
course, I am not sure what the "(st11)" means afterward.

Thanks,
Rob

Robert Mazur <no-one@no-domain.com> wrote:
> I Google'd the config details I would need for the /kernel/drv/st.conf
> entry and found:

> tape-config-list=
> "SEAGATE DAT 06240-XXX", "Seagate DAT Drive", "SEAGATE_DAT";
> SEAGATE_DAT = 1,0x34,0,0xd639,4,0x00,0x8C,0x8C,0x8C,3;

You generally don't need to add stuff like this unless you're having
trouble with it.

> Target 4
> Unit 0 Removable Tape Archive Python 06408-xxx8071

> I was happy to see something recognized, but I suppose I was a little
> suprised to see it listing "Python" rather than a Seagate device.

Since the first string in tape-config-list has to match the device, your
entry is probably not being used.

> I noticed a handful of entries in /dev/rmt/. I attempted writing to the
> drive with:
> tar cvf /dev/rmt/0 /export/home/my_name/test/*

> and got back: tar: /dev/rmt/0: I/O error

> Having a look in /var/adm/messages I see:
> Sep 19 11:38:36 sunking scsi: [ID 365881 kern.info]
> /pci@1f,4000/scsi@3,1/st@4,0 (st11):
> Sep 19 11:38:36 sunking <Archive Python 4mm Helical Scan>
> Sep 19 11:38:36 sunking scsi: [ID 193665 kern.info] st11 at glm1: target
> 4 lun 0
> Sep 19 11:38:36 sunking genunix: [ID 936769 kern.info] st11 is
> /pci@1f,4000/scsi@3,1/st@4,0

This indicates that it's using the entries in the st driver, not yours.
(The item in <> should be the second field of the tape-config-list
entry).

% strings /kernel/drv/st | grep Python
ARCHIVE Python 04106
ARCHIVE Python 28388
ARCHIVE Python
Archive Python 4mm Helical Scan

So this entry is included.

Can you do mt -f <drive> status with a tape inserted? Can you read from
a known good tape? Is there any chance the drive itself is damaged?

You can try modifying the st.conf entry's first field to match your
drive, but I'm unfamiliar with that model.

> So, do you think the details above are pointing me at having the wrong
> config lines in my st.conf?

Your line is definitely not matching the drive.

> Or, are the details from probe-scsi-all suggesting I am stepping on
> the same SCSI id?

I don't see how that would happen.

> I have the switch on the back of the DAT drive set to "4"...I don't
> know if the scsi@3 part in the probe-scsi-all results is significant
> to my problem.

No. That's just an internal address for the scsi controller itself.
The 'st@4,0' is the part that says target 4, lun 0.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

Robert Mazur <no-one@no-domain.com> wrote:
> /pci@1f,4000/scsi@3,1/st@4,0

> I am guessing here, but it looks like Solaris is recognizing my DAT
> drive at scsi id 4, with the piece that says "st@4". Am i right?

Yes.

> Of course, I am not sure what the "(st11)" means afterward.

That's the device that the kernel has mapped to it (from the st
driver). For the most part, you don't care about that number. You can
see the mapping in /etc/path_to_inst, but that's not usually important.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

Darren Dunham wrote:
> This indicates that it's using the entries in the st driver, not yours.
> (The item in <> should be the second field of the tape-config-list
> entry).
>
> % strings /kernel/drv/st | grep Python
> ARCHIVE Python 04106
> ARCHIVE Python 28388
> ARCHIVE Python
> Archive Python 4mm Helical Scan
>
> So this entry is included.
>
> Can you do mt -f <drive> status with a tape inserted? Can you read from
> a known good tape? Is there any chance the drive itself is damaged?
>

Thanks for the help. I have this resolved, but in an unexpected way.

Upon your suggestion, I tried accessing the tape using mt. As usual, I
got an I/O error when trying /dev/rmt/0. I was not clear (still aren't)
on what all the other symbolic links were in my /dev/rmt/
directory....items like:
0, 0b, 0bn, 0c, 0cb, 0cbn, 0cn, 0h,.....etc.

So I started trying mt -f /dev/rmt/<each_of_the_entries_above>

When I got to /dev/rmt/0l, we had contact, and I could make full use of
some tar commands. I saw in a doc somewhere that using /dev/rmt/0n
would prevent the tape from rewinding after the tape was written to.
What is the meaning of all the other entries/links?

So, either the drive was working all along and I was trying to change
/kernel/drv/st.conf a few dozen times for no reason, or maybe changes
were required even before I stumbled on /dev/rmt/0l? I suspect the
former, but some trial and error would let me know.

For now, I have some backing up to do. Thanks for all the help guys.

Rob

> Thanks for the help. I have this resolved, but in an unexpected way.
>
> Upon your suggestion, I tried accessing the tape using mt. As usual, I
> got an I/O error when trying /dev/rmt/0. I was not clear (still aren't)
> on what all the other symbolic links were in my /dev/rmt/
> directory....items like:
> 0, 0b, 0bn, 0c, 0cb, 0cbn, 0cn, 0h,.....etc.
>
> So I started trying mt -f /dev/rmt/<each_of_the_entries_above>
>
> When I got to /dev/rmt/0l, we had contact, and I could make full use of
> some tar commands. I saw in a doc somewhere that using /dev/rmt/0n
> would prevent the tape from rewinding after the tape was written to.
> What is the meaning of all the other entries/links?
>

execute "man st" and go to the bottom of page 11 to see the meaning of
this device entries.

Robert Mazur <no-one@no-domain.com> wrote:
> Upon your suggestion, I tried accessing the tape using mt. As usual, I
> got an I/O error when trying /dev/rmt/0. I was not clear (still aren't)
> on what all the other symbolic links were in my /dev/rmt/
> directory....items like:
> 0, 0b, 0bn, 0c, 0cb, 0cbn, 0cn, 0h,.....etc.

The 'st' man page has all the answers. There's a density flag
(l|m|h|u|c) a BSD compatibility flag (b) and the selection of the
non-rewind device (n). I'd use 0cbn unless you had a reason not to.

> So I started trying mt -f /dev/rmt/<each_of_the_entries_above>

> When I got to /dev/rmt/0l, we had contact, and I could make full use of
> some tar commands.

What was the output on one of the devices that didn't work?

> I saw in a doc somewhere that using /dev/rmt/0n
> would prevent the tape from rewinding after the tape was written to.
> What is the meaning of all the other entries/links?

No. 0n leaves the tape in position after being written to (so you can
write something else afterward). 0 (no n) automatically rewinds the
tape after the first write is complete. That can cause problems if you
don't expect it.

> So, either the drive was working all along and I was trying to change
> /kernel/drv/st.conf a few dozen times for no reason, or maybe changes
> were required even before I stumbled on /dev/rmt/0l? I suspect the
> former, but some trial and error would let me know.

Not all drives make use of all the density flags. Some drives (like the
mammoth 8mm) treat them all identically. When they're used to
distinguish between different densities, l is the bottom. Think (l)ow,
(m)edium, (h)igh, and ((u)ltra high or (c)ompressed).

For instance the DLT7000 drive will write a tape in uncompressed DLT4000
compatibility mode (20GB capacity) when using the 'l' density. It will
write in compressed DLT7000 mode (~70GB capacity) when using the 'u' or
'c' density.

I would normally expect the 'c' device (usually as 'cbn') to be the
correct one. Some combinations of drive and media may not be valid for
all densities.

> For now, I have some backing up to do. Thanks for all the help guys.

Good luck.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >