From owner-freebsd-scsi  Tue Mar  5 07:02:56 1996
Return-Path: owner-freebsd-scsi
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA29636
          for freebsd-scsi-outgoing; Tue, 5 Mar 1996 07:02:56 -0800 (PST)
Received: (from jmb@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id HAA29629
          Tue, 5 Mar 1996 07:02:53 -0800 (PST)
From: "Jonathan M. Bresler" <jmb>
Message-Id: <199603051502.HAA29629@freefall.freebsd.org>
Subject: Re: Archive Anconda Tape drive 1.35GB
To: gibbs@freefall.freebsd.org (Justin T. Gibbs)
Date: Tue, 5 Mar 1996 07:02:53 -0800 (PST)
Cc: freebsd-scsi
In-Reply-To: <199603051438.GAA28607@freefall.freebsd.org> from "Justin T. Gibbs" at Mar 5, 96 06:38:23 am
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk

Justin T. Gibbs wrote:
> 
> >The recommended tape is the 3M Magnus DC-9135.   Tech support
> >recommends that the SCSI controller be configured for 5 MB/s
> >operation, SYNC disabled, SCSI disconnect=no, and jumper jp6 open.
> >(the jumper information is wrong.  jp6 open == SCSI-1, jp6 shorted
> >== SCSI-2)  The tech doc is available from Connor's fax-back service:
> >1-408-456-4903 (?) document 2206 (?) (no fax machine here, i will
> >verify this tomorrow)
> 
> I think the tech people are off in space.  Async maxes out at ~3MB/s,
> so it doesn't matter what the controller's sync rate is set to.  You
> also want to have disconnection enabled for the driver or it will
> hand up the SCSI bus for other devices while its doing things like
> rewinding. Ughh.

	would not surprise me that the tech staff there is lost.
	their own docs are wrong.
> 
> >When operating as a SCSI-1 device (jp6 open) the drive does not
> >conform to SCSI-1.  The drive "locks" the scsi bus during at least
> >some mt operations (eg fsf, rewind, rewoffl).
> 
> This is because it doesn't disconnect correct?

	yes, that is my understanding.  but ONLY when set to SCSI-1 .
	when set to SCSI-2 the mt operations are fine.
	/sbin/dump however behaves differently.
	if the latetime variable in ncr.c crosses a threshhold
	the driver (nr.c) assumes that the "ncr scsi engine"
	has dies and reinitializes the scsi card.
	then all hell breaks loose and a reboot is needed to get the
	tape drive and the scsi card to cooperate again.
> 
> >When operating as a SCSI-2 device (jp6 shorted) the drive does not
> >lock the scsi bus during the operations listed above.  However to
> >get the ncr working with /sbin/dump, the ncr requires a patch
> >extending the latetime from 10 secs to a larger value.  presently
> >i am using 20 minutes.  ;(  but it works and its fast!   it does
> >not lock the bus while the dump is being written to tape.
> 
> What does the latetime value affect?

	i am not a scsi expert, plese see the code ~line 4854 in
	/sys/pci/ncr.c

	if you are interestted  will use the debug capabilites of
	ncrcojtrol to pursue this.  but i waill need help.  i aint
	no scsi expert (by a long short but i am learning more each time
	i work on this :)