Date: Sun, 21 Apr 1996 13:45:18 -0400 From: Andrew Herdman <andrew@whine.com> To: questions@freebsd.org Cc: scsi@freebsd.org Subject: Re: Problems with the st driver in 2.2-960323-SNAP Message-ID: <Pine.BSF.3.91.960421134255.192A-100000@why> In-Reply-To: <Pine.BSF.3.91.960417194140.1018A-100000@why>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960421134255.192A-100000>