From owner-freebsd-questions  Sun Apr 21 10:45:51 1996
Return-Path: owner-questions
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id KAA27291
          for questions-outgoing; Sun, 21 Apr 1996 10:45:51 -0700 (PDT)
Received: from cicerone.uunet.ca (cicerone.uunet.ca [142.77.1.11])
          by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id KAA27250
          Sun, 21 Apr 1996 10:45:45 -0700 (PDT)
Received: from why ([205.150.249.1]) by cicerone.uunet.ca with SMTP id <177091-2>; Sun, 21 Apr 1996 13:45:25 -0400
Date: Sun, 21 Apr 1996 13:45:18 -0400
From: Andrew Herdman <andrew@whine.com>
X-Sender: andrew@why
To: questions@freebsd.org
cc: scsi@freebsd.org
Subject: Re: Problems with the st driver in 2.2-960323-SNAP
In-Reply-To: <Pine.BSF.3.91.960417194140.1018A-100000@why>
Message-ID: <Pine.BSF.3.91.960421134255.192A-100000@why>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-questions@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

After some considerable poking around in the scsi code I found the 
following changes in st.c were causing the problem.  

in

st_open:

scsi_prevent(sc_link, PR_PREVENT, 0);   /* who cares if it fails? */

and

st_close:

scsi_prevent(sc_link, PR_ALLOW, SCSI_SILENT);

Now I do agree that calling this function is appropriate.  But it doesn't 
seem to work properly.  I'm not a scsi expert so I'm not sure why it fails.

Andrew


On Wed, 17 Apr 1996, Andrew Herdman wrote:

> After upgrading to the recent snap, I have been having problems with my 
> Archive Python 4mm Dat drive on a buslogics 946c and the nrst device.
> 
> Using tar i can do the following:
> 
> tar cf /dev/nrst0 /dir1
> tar cf /dev/nrst0 /dir2
> tar cf /dev/nrst0 /dir3
> mt -f /dev/rst0 rewind
> 
> tar tvf /dev/nrst0
> 	<lists files from /dir1>
> tar tvf /dev/nrst0
> 	<does nothing>
> tar tvf /dev/nrst0
> 	<lists files from /dir2>
> tar tvf /dev/nrst0
> 	<does nothing>
> tar tvf /dev/nrst0
> 	<lists files from /dir3>
> 
> Using dump, i get the following:
> 
> # dump 9uBf 2000000 /dev/nrst0 /dev/rsd0a
>   DUMP: Date of this level 9 dump: Wed Apr 17 19:41:25 1996
>   DUMP: Date of last level 0 dump: Sat Apr 13 08:09:32 1996
>   DUMP: Dumping /dev/rsd0a (/) to /dev/nrst0
>   DUMP: mapping (Pass I) [regular files]
>   DUMP: mapping (Pass II) [directories]
>   DUMP: estimated 15855 tape blocks on 0.01 tape(s).
>   DUMP: dumping (Pass III) [directories]
>   DUMP: dumping (Pass IV) [regular files]
>   DUMP: DUMP: 15882 tape blocks on 1 volumes(s)
>   DUMP: finished in 92 seconds, throughput 172 KBytes/sec
>   DUMP: level 9 dump on Wed Apr 17 19:41:25 1996
>   DUMP: Closing /dev/nrst0
> st0: not ready
>   DUMP: DUMP IS DONE
> 
> 
> If I do multiple dumps on one tape it rewinds to the beginning and erases 
> the previous dump (not a very effective backup system ;).  This all 
> worked perfectly fine with 2.1.0-RELEASE.  I've been poking thru the 
> kernel sources (doing diff's between the 2 kernel sources) and haven't 
> found anything yet.  Is this a known problem?  Would the people working 
> on this area contact me, I'd like to help as much as I can to help solve 
> the problem.
> 
> Thanks
>    Andrew
> 
>