From owner-aic7xxx Tue Feb 29 22:24: 1 2000 Delivered-To: aic7xxx@freebsd.org Received: from lacrosse.corp.redhat.com (lacrosse.corp.redhat.com [207.175.42.154]) by hub.freebsd.org (Postfix) with ESMTP id 2328D37BE13 for ; Tue, 29 Feb 2000 22:23:57 -0800 (PST) (envelope-from dledford@redhat.com) Received: from redhat.com ([10.0.0.25]) by lacrosse.corp.redhat.com (8.9.3/8.9.3) with ESMTP id BAA26874; Wed, 1 Mar 2000 01:23:46 -0500 Message-ID: <38BCB7A3.B7A25478@redhat.com> Date: Wed, 01 Mar 2000 01:24:35 -0500 From: Doug Ledford Organization: Red Hat, Inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14-1.1.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Metod Kozelj Cc: aic7xxx@FreeBSD.ORG Subject: Re: AHA-2940UW, DLT, alpha & aic driver References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-aic7xxx@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Metod Kozelj wrote: > > Hello, > > I'm having slight problems while using HP SureStore DLT40 connected to > AHA2940UW on Linux/Alpha. > > My system is alpha, running basically RedHat 5.1 with kernel 2.2 patches > and kernel 2.2.14. I'm using stock aic driver. > > 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). > 'mt -f /dev/nst rewi' works fine, 'mt -f /dev/nst0 status' > prints some meaningful data. > > 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. -- Doug Ledford http://people.redhat.com/dledford Please check my web site for aic7xxx updates/answers before e-mailing me about problems To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message