Date: Thu, 5 Sep 2002 12:57:34 -0400 From: "John S. Bucy" <bucy@ece.cmu.edu> To: scsi@freebsd.org Subject: Re: New scsi_target code Message-ID: <20020905165734.GE10500@catalepsy.pdl.cmu.edu> In-Reply-To: <Pine.BSF.4.21.0209050143320.1450-100000@root.org> References: <Pine.BSF.4.21.0209050143320.1450-100000@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Sep 05, 2002 at 01:54:08AM -0700, Nate Lawson wrote: > I have rewritten the scsi_target driver and usermode client with a much > simpler model suggested by Justin Gibbs. The kernel driver receives > commands in the form of CCBs via write(2) and returns completed CCBs to > usermode via read(2). The included sample client is much simpler as well, > implementing only RBC (simple hard drive command set). > > What is this useful for? It allows anyone with an HBA to emulate various > SCSI target devices for reverse engineering initiator implementations, > debugging, host-host communication, and many other uses. Because it > operates at the CAM layer, it should work with multiple transports > (parallel SCSI, FC, ...) > > Currently, the code works to the point of passing camcontrol rescan and a > few reads and writes with two Adaptec 2940U2Ws (ahc driver). However, > there is an unknown bug where after a few commands (even just TUR), the > target hangs after sending a CTIO and the initiator aborts the > command. As such, the code is ALPHA QUALITY and may hang your system. > > For more information, see the included README and manpages. Comments are > needed and appreciated. 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. 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.. 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. 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. john To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020905165734.GE10500>