From owner-freebsd-scsi Wed Apr 28 9:12:54 1999 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 17E8B14E94 for ; Wed, 28 Apr 1999 09:12:47 -0700 (PDT) (envelope-from mjacob@feral.com) Received: from feral.com (mjacob@feral.com [192.67.166.1]) by feral.com (8.8.7/8.8.7) with ESMTP id JAA25129; Wed, 28 Apr 1999 09:12:31 -0700 Date: Wed, 28 Apr 1999 09:12:30 -0700 (PWT) From: Matthew Jacob Reply-To: mjacob@feral.com To: amobbs@allstor-sw.co.uk Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: QIC tape problems on -stable (was: hanging `tar xfvR /dev /nrst0' process, can i debug it?) In-Reply-To: <80256761.00572CBF.00@mail.plasmon.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > > > > >These are *amazingly* broken drives then. The SCSI specification says that > >a write of *zero* filemarks is to flush any pending writes. You have to do > >this when you do a read hardware position in order to avoid an ambiguity > >in the spec as to the true position as affected by data in the tape drive > >buffer. > > Doesn't Read Position (34h) give all the info you need, i.e. Physical pos., > logical pos. and number of blocks in buffer? I agree that flushing is > safer, but surely one could avoid it if necessary. > Now *that's* an area I would mistrust the f/w on- yes, you get number of blocks in the buffer (you use a flag in the cdb to select SCSI logical vs. hardware, and there's *nothing* that says that any device has to support either. STK drives puke on SCSI logical block reporting. DLT's puke on hardware block reporting). I think the patch I sent is probably the right approach. It's always a tradeoff- features vs. supporting really broken h/w. It really ticks me that this is broken. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message