Quite a while ago I sent off the following plea:
>
>Folks,
> I have a nice, shiny, new DLT4000 drive that I want to put
>onto a SS20 running Solaris 2.5. The problem, in short, is that it is
>not recognised by the OS - BEFORE you start off about st.conf read
>below!!!
>
>Things I have tried:
>
>1) The drive is there doing a probe-scsi. There are no scsi id
>conflicts and I believe the cable to be ok.
>
>2) The drive is properly terminated with an active terminator. There
>are some hard disks on the same chain that are functioning fine.
>
>3) I have copied a _functioning_ st.conf from another machine (this
>other machine, an Ultra, was able to recognise & talk to the DLT drive
>fine).
>
>4) I have applied all the recommended patches for Solaris 2.5.
>
>5) The two exabytes that I am trying to replace work fine.
>
>6) The st.conf is fine - it works on other machines.
>
>Has anyone got any other things that I can try?
>
Thanks to all the people who replied. A common refrain was to ask if
I had done a "boot -r" which is a reasonable suggestion since I did
not mention it (I had done this I just failed to put it in my message)
Frank Pardo came closest to hitting the nail on the head by suggesting
I remove all the other scsi devices from the chain and see what
happened. I actually did this and the kernel found the DLT.
To cut a long story short, there was a double termination of the scsi
bus the DLT was on. One of the hard disks had the termination
jumpered on when it should not have. As to why the thing worked with
_more_ scsi devices on the chain (i.e. the two exabytes) is something
that I will leave to the philosophers - now that the bus is only
terminated once the DLT works fine which makes me happy since they are
excellent, fast drives.
Thanks to these people for their suggestions:
Steve Phelps <steve@epic.co.uk>
Jerry Cunningham <gcunning@census.gov>
Chris Marble <cmarble@orion.ac.hmc.edu>
Dave_Berry@themoneystore.com
"F. David Sinn" <dsinn@dsinn.seanet.com>
"Jeff J. Dingbaum" <dingbaum@hep.net>
fpardo@tisny.com (Frank Pardo)
"Theodore S. Kapela" <kapela@quasar.sbi.com>
augusto@Brazil.Sun.COM (Augusto Ricardo Tin Pires [ENS System Technologist])
sunman@oak.london.waii.com (Robert.Gillespie@waii.com)
Fedor Gnuchev <qwe@ht.eimb.rssi.ru>
Lewis Burgess <burgess@quickturn.com>
leach@oce.orst.edu (Tom Leach)
Here are the non-"boot -r" responses just in case someone else has a
similar problem:
From: Steve Phelps <steve@epic.co.uk>
Subject: Re: SS20 will not recognise a DLT drive.
content-length: 926
Status: RO
At 19:01 05/02/97 +1030, you wrote:
>According to Steve Phelps:
>>
>>When you say it is not recognised by the OS, what are the symtoms?
>
>When the st driver is being loaded - it says it cannot be loaded,
>presumably because it decides there are no tape drives.
Is this the st kernel module? Can you see the module 'st' when you do
run 'modinfo' as root? What is the exact message from /var/adm/messages?
It might be worth making sure the st module is not loaded (using modunload
if necessary) and then running
truss -f modload drv/st
For the working case (Exabyte) and the not-working case (DLT) and seeing if
there is an obvious point of failure for the not-working case.
The same
>driver on the same machine will happily load when I put some exabytes
>on the machine.
>
The st.conf file can be setup so that certain types of drive will only
be recognized on certain SCSI IDs. Could this be the problem?
From: Jerry Cunningham <gcunning@census.gov>
We had the _exact_ same problem. We got it to work by going back and
installing the "OEM Support" (or something like that) module from the CD.
From: Chris Marble <cmarble@orion.ac.hmc.edu>
Does the drive show up during the reconfigure boot?
Can you see messages about it in the "dmesg" output?
Did you remove the /dev/rmt entries before you did the
reconfigure boot? If you don't the system will often not
overwrite them.
From: "F. David Sinn" <dsinn@dsinn.seanet.com>
Have you confirmed that the id string in your st.conf matches the id string from the probe-scsi?
This is a brand new DLT4000, so it could be identifying itself differently then the other DLT's that you have.
From: fpardo@tisny.com (Frank Pardo)
Your message didn't say what SCSI devices, in what order, are
attached to your SS20. Sometimes that makes a difference...
Have you tried to boot the system with only the DLT4000 and
nothing else attached to it?
From: sunman@oak.london.waii.com (Robert.Gillespie@waii.com)
You didn't mention a few things:-
ENSURE the DLT 400 entry is UNCOMMETED in st.conf
rm /dev/rmt/* You may have an "old" entry not being updated
touch /reconfigure
reboot
(boot -rv)
Below is for my DLT 2000XT
palm{rob}% ls -lFAt st.co*
-rw-r--r-- 1 root 5441 Sep 11 16:44 st.conf
-rw-r--r-- 1 root 5437 Sep 11 16:28 st.conf.DLT_1
-rw-r--r-- 1 root 4755 Oct 25 1995 st.conf.generic
palm{rob}% diff st.conf.generic st.conf
0a1,13
> tape-config-list =
> "DEC DLT2000", "DEC DLT2000XT 20/30 Gbyte 1/2\" Cartridge", "DEC-DLT",
> "DEC DLT4", "DEC DLT4000", "DLT4000",
> "Quantum DLT4", "Quantum DLT", "DLT4000",
> "EXABYTE EXB8500C", "Exabyte 8mm w/compression", "EXB8500C",
> "EXABYTE EXB-8505", "Exabyte 8mm hh w/compression", "EXB8500C",
> "EXABYTE EXB-8205", "Exabyte 8mm hh w/compression", "EXB8205",
> "EXABYTE EXB-8500", "Exabyte 8mm 5GB", "EXB8500";
> DEC-DLT = 1,0x33,16384,0x0239,4,0x17,0x18,0x80,0x81,3;
> DLT4000 = 1,0x35,0,0x0239,4,0x80,0x81,0x82,0x83,3;
> EXB8500C= 1,0x35,0,0x0239,4,0x14,0x15,0x8c,0x8c,3;
> EXB8205 = 1,0x35,0,0x0239,4,0x14,0x90,0x90,0x90,3;
> EXB8500 = 1,0x35,0,0x0239,4,0x14,0x15,0x8c,0x8c,3;
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:46 CDT