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