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 ; 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 ; 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 To: "John S. Bucy" Cc: scsi@freebsd.org Subject: Re: New scsi_target code In-Reply-To: <20020905165734.GE10500@catalepsy.pdl.cmu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: 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