From owner-aic7xxx Tue Feb 29 22:50: 6 2000 Delivered-To: aic7xxx@freebsd.org Received: from hmljs.rzs-hm.si (hmljs.rzs-hm.si [193.2.208.10]) by hub.freebsd.org (Postfix) with ESMTP id 4B7D537BC50 for ; Tue, 29 Feb 2000 22:50:01 -0800 (PST) (envelope-from metod.kozelj@rzs-hm.si) Received: from hmljhp.rzs-hm.si (hmljhp.rzs-hm.si [193.2.208.12]) by rzs-hm.si (PMDF V5.2-31 #39364) with ESMTP id <01JMICP0XRQQ000G5I@rzs-hm.si> for aic7xxx@FreeBSD.ORG; Wed, 1 Mar 2000 06:49:57 GMT Received: from localhost by hmljhp with SMTP (8.7.1/8.7.1) id HAA28353; Wed, 01 Mar 2000 07:49:56 +0100 (CET) Date: Wed, 01 Mar 2000 07:49:55 +0100 (CET) From: Metod Kozelj Subject: Re: AHA-2940UW, DLT, alpha & aic driver In-reply-to: <38BCB7A3.B7A25478@redhat.com> To: Doug Ledford Cc: Metod Kozelj , aic7xxx@FreeBSD.ORG Reply-To: Metod Kozelj Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, On Wed, 1 Mar 2000, Doug Ledford wrote: > > My problem real problem is, that 'mt -f /dev/nst0 fsf' doesn't do > > anything. > > In what context? Several tape drives I've worked with in the past will accept > the fsf command silently, seeming to do nothing, but if you actually tried to > read or write to the tape after executing the command, then the drive does the > reposition before the read or write. In my experience, it works just fine. > Regardless though, this wouldn't be an aic7xxx driver problem, this would be a > problem in the scsi tape driver (if it is even a problem). Another member of this list suggested that this was a problem of mt, shipped with RH5.1 and RH5.2. Upgrading to mt shipped with RH6.1 indeed solved that problem. Regarding your suggestion: if I do mt -f /dev/nst0 fsf 1 tar -tvf /dev/nst0 it still acesses the first archive on tape. So it never actually performs forward seek. > > There's some funny thing about /proc/scsi/aic7xxx/0 contents: statisctics > > for the DLT never change while statistics for disks do change. > > The driver uses the cmd->request.cmd variable as the main indicator of whether > the command is a read or a write command. If the upper layer SCSI driver > doesn't fill that variable in, then you see the behavior you are seeing. > Furthermore, we only track the transfer data on commands that actually use a > command buffer, there are a number of commands, such as fsf, that don't > trigger any sort of data length calculation in the driver. So you are suggesting that even if I actually read the data from DLT (using 'tar -tvf /dev/nst0'), it's just fine for stats not to reflect any reads? And that this is st driver's failure? Regards, Metod Metod Kozelj mailto:Metod.Kozelj@rzs-hm.si /\ Ne posiljajte mi smeti ker grizem! http://www.rzs-hm.si/ / \ Don't spam me for I bite! _______________________________________/ \__________________________________ ---- perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message