SCSI Tape drive question

[Cole Tuininga]

On Thu, 2004-06-17 at 08:31, bscott at ntisys.com wrote:
> On Thu, 17 Jun 2004, at 7:19am, colet at code-energy.com wrote:
> > I've set up a SCSI tape drive on a system.  The drive is a SONY AIT
> > *mumble mumble* on a symbios based card. 

Some of the specifics were a little difficult to find, as the system is
in the field, and not close by.  Additionally, the folks who have it are
not very technical...

> Model of tape drive.  

It's a Sony AIT SDX-D400C.

> Model or chipset of SCSI host adapter 

I should mention that the SCSI card for the tape drive is a secondary
SCSI card.  The primary is a megaraid card (this is a Dell system) being
used for an internal RAID array.  The only item on the symbios card is
the tape drive on the external channel.  There "shouldn't" be any
conflicts with adapter/SCSI ids as far as I can tell.

lspci shows:

02:01.0 RAID bus controller: LSI Logic / Symbios Logic (formerly NCR):
Unknown device 1960 (rev 01)
03:02.0 SCSI storage controller: LSI Logic / Symbios Logic (formerly
NCR) 53c895 (rev 02)

Cat'ing /proc/scsi/scsi shows:

Host: scsi0 Channel: 00 Id: 15 Lun: 00
  Vendor: SONY     Model: SDX-400C         Rev: 0702
  Type:   Sequential-Access                ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 00 Lun: 00
  Vendor: MegaRAID Model: LD0 RAID5 39760R Rev: 3.41
  Type:   Direct-Access                    ANSI SCSI revision: 02


> (or at least the name of the Linux driver).

I'm using the sym53c8xx driver.  I also have the AMI MegaRAID support
turned on for the RAID array.

>   Linux distribution and release.  

Debian woody.

> Kernel version.

2.4.26

>   If you look as "ps aux", I'm sure you'll see the "mt" process has status
> of 'D', which is short for "uninterruptible sleep".  That means the process
> is sleeping on a kernel system call.  You can send the SIGKILL signal, but
> the process will not receive it until the kernel call completes and the
> process wakes up again.  The kernel system call in question is doubtless a
> call to the SCSI device layer.

That makes sense to me.

>   The question is, what is the SCSI driver doing?  Have you checked syslog
> and dmesg for any messages?

Ayup - didn't see anything at all.  Checked the kernel log as well.  The
only thing I see is each night at midnight (when the backup cronjob
runs), I see a line similar to:

Jun 17 00:00:01 crrc kernel: sym53c895-0-<15,*>: FAST-20 WIDE SCSI 40.0
MB/s (50.0 ns, offset 15)

That's about it though.

>   The "erase" command typically takes a really long time to complete.  

Only if you consider 2+ hours a really long time.  ;)

> That might indicate a problem with SCSI device disconnection.  That is 
> when the initiator sends a command to the target, and then the 
> target "disconnects" from the SCSI bus while the command completes.  
> This frees the SCSI bus for other operations.  If I knew anything 
> about your equipment, I might be able to give further insight, but 
> since all I know is that you have a tape drive, I can only speak in 
> generalities.

Does the above information help to give you any other ideas?

>   BTW, why are you running erase, anyway?  It's typically not needed 
> for modern tape technologies (such as AIT).

Truth be told, I didn't know that.  Why is it not necessary?

>   Aside from giving us the vital information already requested: I 
> would recommend checking firmware revisions on the tape drive, 
> host adapter, and mainboard.  See if updates are available, and 
> if so, install them.

I suspect not, only because this system was deployed last week and they
were all up to date then.  I'll check anyway though.

-- 
"Experience is something you don't get until just after you need it."

Cole Tuininga
Lead Developer
Code Energy, Inc
colet at code-energy.com
PGP Key ID: 0x43E5755D