From owner-freebsd-scsi  Fri Sep  6 17:30:22 2002
Delivered-To: freebsd-scsi@freebsd.org
Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 5882237B400
	for <scsi@freebsd.org>; Fri,  6 Sep 2002 17:30:18 -0700 (PDT)
Received: from rootlabs.com (root.org [67.118.192.226])
	by mx1.FreeBSD.org (Postfix) with SMTP id A345543E77
	for <scsi@freebsd.org>; Fri,  6 Sep 2002 17:30:17 -0700 (PDT)
	(envelope-from nate@rootlabs.com)
Received: (qmail 6012 invoked by uid 1000); 7 Sep 2002 00:30:19 -0000
Date: Fri, 6 Sep 2002 17:30:19 -0700 (PDT)
From: Nate Lawson <nate@root.org>
To: "John S. Bucy" <bucy@ece.cmu.edu>
Cc: scsi@freebsd.org
Subject: Re: New scsi_target code
In-Reply-To: <20020905165734.GE10500@catalepsy.pdl.cmu.edu>
Message-ID: <Pine.BSF.4.21.0209061723010.5707-100000@root.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Thu, 5 Sep 2002, John S. Bucy wrote:
> Cool!  I've been working on this off and on on a research project at
> CMU.  I believe that I've run into the same timeouts/hangs.  I've
> wanted to use isp instead of ahc but the last time I tried it --
> probably 6 months ago now -- I couldn't get isp to do target mode.  I
> tried several different adaptec cards -- 2940UW/U2W/29160/etc -- and
> was never able to get rid of the timeouts.

isp can do target mode.  Last time I used it, there were problems with
residuals (i.e. CTIO transfers > 8-12k).  Matt may have more recent
information on this.
 
> I don't remember right now but I think that there were one or two
> commands -- i.e. TUR -- that I handled in kernel rather than going
> down to userspace but I doubt that that extra latency is the cause of
> the timeouts..

In this driver, all commands are handled in usermode, which simplifies the
data path a lot.

> Are you doing tagged queueing?  I was in the midst of hacking on that
> when I got preempted to work on another project.  I had sort of a
> hacked way of dealing with it; I pass the whole CDB through the ioctl
> and only pass bus-transfer data through read() and write().  I then added
> an ioctl to set the tag that the next read() or write() data transfer
> goes with and there's an array in the driver that keeps up with all of
> the outstanding commands. 

This driver passes the CCBs (~30-120 bytes) through read/write and the
data through the cam_periph_mapmem() function directly to the SIM.  Tagged
queueing will be handled fully in usermode.

There is a command line option to enable tagged queueing but it is not
fully implemented.  It advertises the capability in the inquiry response
but does not implement the subsequent mode sense/select.  Thus, I do not
test with tagged queuing yet.

> I'll be working on it again this fall and will definitely be
> interested in incorporating others' work with mine; my lab wants to
> release our code as soon as we think its stable enough to be useful to
> other research projects.

Great.  Any testing or comments on the driver would be nice.

-Nate


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message