Yes,
my box is a Sparc E-450 running Sol 6.
I am using the SST driver for Solaris 6.
I think it(SST Driver) is the predecessor to Solaris' sgen driver for
Sol 7 and 8.
Here are the boot messages for the Jukebox robotic arm and its 2 QUANTUM
drives
Sep 4 12:30:12 sun1 unix: sst3: found Changer device at tgt0,
lun0
Sep 4 12:30:12 sun1 unix: sst3: Vendor/Product ID = STK 9730
Sep 4 12:30:12 sun1 unix: sst3 at pci1000,f7:
Sep 4 12:30:12 sun1 unix: target 0 lun 0
Sep 4 12:30:12 sun1 unix: sst3 is /pci@1f,4000/scsi@4,1/sst@0,0
--
--
Sep 4 12:30:17 sun1 unix: st57: <QUANTUM DLT7000>
Sep 4 12:30:17 sun1 unix: st57 at pci1000,f7:
Sep 4 12:30:17 sun1 unix: target 1 lun 0
Sep 4 12:30:17 sun1 unix: st57 is /pci@1f,4000/scsi@4,1/st@1,0
*******
*******This Bottom entry is the Problem Tape Drive
*******
Sep 4 12:30:17 sun1 unix: st58: <QUANTUM DLT7000>
Sep 4 12:30:17 sun1 unix: st58 at pci1000,f7:
Sep 4 12:30:17 sun1 unix: target 2 lun 0
Sep 4 12:30:17 sun1 unix: st58 is /pci@1f,4000/scsi@4,1/st@2,0
and, as I said before, I can write and read and such to the tape drive.
As Tien That Ton stated earlier, I am starting to wonder if the issue
might be with the Robotic Arm.
AFAIK, the arm recalibrates itself upon powering on (At least that's
what the messages say).
If I knew the SCSI commands, I'd send some SCSI commands to the robotic
arm directly.
Would I find such a thing in the source code of chg-scsi, maybe in
chg-scsi.c?
-----Original Message-----
From: Gene Heskett [mailto:gene_heskett AT iolinc DOT net]
Sent: Tuesday, September 10, 2002 7:25 PM
To: Quinn, Richard C. - Collinsville IT; amanda-users AT amanda DOT org
Subject: Re: Working with multiple tape drives----- Ammended
On Tuesday 10 September 2002 16:36, Quinn, Richard C. - Collinsville
IT wrote:
>Hi again,
>
>I think I've narrowed it down just a spell.
>Gene was helpfull with some advice regarding the "tapedev"
> variable in amanda.conf.
>Unfortunately that didn't seem to fix the issue, which I think MAY
> be scsi related and not amanda related.
>
>In a nutshell the problem is this:
>I cannot get the robotic arm to take the tapes in and out of one
> of my 2 DLT drives.
>I will set up chg-scsi to only configure for one drive(the one
> that is being ignored by my robotic arm).
>I'll send a chg-scsi -reset command and get this error:
>0 slot 0 move failed
>
>
>
>However, upon issuing the chg-scsi command, the tape drive will
> rewind and offline itself, and yes, I can do ufsdumps to the
> drive. So, if it is a SCSI problem, I am not sure what or how,
> AFAIK, ufsdump and mt rew ultimately issue scsi commands don't
> they?
>
>It doesn't seem to be the drive so much as the arm going to the
> drive.
>
>Just before I get this ''move failed'' error, the robotic arm will
> move in front of the drive, then move down an inch, then back up
> an inch, then down, and THEN, I get the ''move failed'' error.
>
>
>
>Here is a snip of the errors I get in
>/tmp/amanda-dbg/chg-scsi-#####.debug and /var/adm/messages
> respectively:
>
>
>
>==================================================================
>== ##### START LookupElement
>##### STOP LookupElement (DTE)
>##### START LookupElement
>##### STOP LookupElement (STE)
>ioctl on 4 failed, errno 5, ret -1
>##### START DecodeSense
>SCSI_ExecuteCommand:Sense Keys
> ErrorCode 1d
> Valid 1
> ASC 90
> ASCQ 10
> Sense key 0F
> Reserved
>==================================================================
>==
> =================================================================
>===
>
>
>Sep 10 14:35:06 sun1 unix: WARNING: /pci@1f,4000/scsi@4,1/sst@0,0
>(sst3):
>Sep 10 14:35:06 sun1 unix: Error for Command: <undecoded cmd
> 0xa5> Error Level: Fatal
>Sep 10 14:35:06 sun1 unix: Requested Block: 0
>Error Block: 0
>Sep 10 14:35:06 sun1 unix: Vendor: STK
>Serial Number:
>Sep 10 14:35:06 sun1 unix: Sense Key: Illegal Request
>Sep 10 14:35:06 sun1 unix: ASC: 0x3a (medium not present),
> ASCQ: 0x0, FRU: 0x0
>==================================================================
>==
>
>
>
>Any ideas?
>
>
>Does anyone speak SCSI?
Not very well I'm afraid. But an idea is beginning to jell in the
back of my mind, and it has to do with SOME drives penchant for
assigning the robot (s) to the same address as the drive itself,
but to a non zero LUN at that address. Now, AFAIK, the lkernel,
when initializing itself, does the device scan, it scans all LUNs
at each address on the bus, and is the major reason for a noticable
pause in the boot proceedings at that point.
Such tomfoolery with the bus address and LUN's is normally recorded
in /var/log/dmesg, so please post that section of it, probably not
more than 20 lines to this list and let us see what was actually
detected and recorded by the kernel at your last bootup. It might
be cluefull to one of us here. Since I see references to sun1 and
unix in that trace above, defining your system to us may also help,
I suspect its not middle of the road linux, but may call for some
sun/solaris expertise I don't have.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.14% setiathome rank, not too shabby for a WV hillbilly
|
