SCSI tape problem

[Michael Meissner]

On Wed, Dec 16, 1998 at 04:42:10PM -0500, Peter Skensved wrote:
> 	I tried posting this to the redhat-list but have not got any responses
> yet so I will try it here  : 
> 
> ---
>  After having upgraded from 5.1 to 5.2 I can no longer position tapes on our
> two SCSI tapedrives using the mt utility. We have an Exabyte 8505 and a 
> Quantum DLT-4000 on an Adaptec 2940 controller ( aic7xxx driver ) in a P-II.
> Commands like mt -f /dev/nst0 fsf 2 return immidiately ( without any errors )
> but there is no tape movement. Only the `rewind' and the `offline' commands do
> something. Reading and writing tapes using tar works fine. The problem
> is not the mt binary itself since it does not matter whether I use the 5.1 
> ( mt-st v 0.4 ) or the 5.2 version ( mt-st v 0.5 ).
> 
>  The positioning commands all worked with 5.1 ( up to and including the 2.0.35
> kernel ) but fail with any of the 5.2 kernels including the latest 2.0.36
> ( dec8/98 ). 
> 
>  st.c appears to be the same for the two kernels ( .35 and .36 ) but the
> underlying aic7xxx driver is quite different. 
>  
>   If anybody else has experienced similar problems or have suggestions I would
> appreciate hearing from the.

The bug is in the mt command that RedHat ships with 5.2, not with the kernel.
The 0.5 version of mt has a bug in that it uses the wrong argument when a -f
option is used on a command that takes a numeric argument (ie, fsf for
instance).  The simplest approach is to upgrade to mt-0.5b.i386.rpm, which is
in the contributed directories on contrib.redhat.com.  A secondary option is to
set the TAPE environment variable and don't use -f /dev/nst1.

There are some tape differences in 2.1.xx kernels.  The ones I've notice in
various 2.1.xx kernels include:

   1)	You must manually pad blocks to the blksize specified via mt;

   2)	Reads leave the tape positioned to the end of the current record, not
	at the beginning of the next record;

   3)	Either the newer ncr53c8xx/aic7xxx drivers are at fault (in which case
	you would see it with 2.0.36), or driver independent code in 2.1.xxx
	made both my ncr53c8xx (TekRam 390F and TekRam 390U) and Adaptec 2940UW
	scsi chains more sensitive to bad termination issues, particularly with
	my older Archive Python DDS-1 tape drives.

-- 
Michael Meissner, Cygnus Solutions (Massachusetts office)
4th floor, 955 Massachusetts Avenue, Cambridge, MA 02139, USA
meissner at cygnus.com,	617-354-5416 (office),	617-354-7161 (fax)

To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message