From owner-freebsd-scsi Fri Jul 4 09:30:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29562 for freebsd-scsi-outgoing; Fri, 4 Jul 1997 09:30:27 -0700 (PDT) Received: from weenix.guru.org (phantasma.bevc.blacksburg.va.us [198.82.200.65]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA29557 for ; Fri, 4 Jul 1997 09:30:25 -0700 (PDT) Received: (from kmitch@localhost) by weenix.guru.org (8.8.5/8.8.5) id MAA07734; Fri, 4 Jul 1997 12:30:21 -0400 (EDT) From: Keith Mitchell Message-Id: <199707041630.MAA07734@weenix.guru.org> Subject: Re: Archive Viper and 3940UW (bad Drive?) In-Reply-To: <199707021928.NAA21948@pluto.plutotech.com> from "Justin T. Gibbs" at "Jul 2, 97 02:26:25 pm" To: gibbs@plutotech.com (Justin T. Gibbs) Date: Fri, 4 Jul 1997 12:30:21 -0400 (EDT) Cc: scsi@freebsd.org X-Mailer: ELM [version 2.4ME+ PL30 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Try going through all of the actions that are performed in st_close and > increase the timeout. I've heard of the prevent causing problems which > was why I bumped up the timeout value, but it could also be the writing > of the filemarks that is causing your problems. After doing this, I noticed that some of my tapes worked and some didn't. After "erasing" all of them they all seem to worked (even on an unmodifed kernel). I was under (I guess false) impression that you didn't have to "erase" them. In the amanda cycle, it just rewinds the tapes and overwrites the data on them. I guess this added a little extra to the filemark or something similar that caused it to take to long (and thus timeout) on the device close. -- Keith Mitchell Head Administrator: acm.vt.edu Email: kmitch@weenix.guru.org PGP key available upon request http://weenix.guru.org/~kmitch Address and URL (c) 1997 Keith Mitchell - All Rights Reserved Unauthorized use or duplication prohibited