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
|