Date: Tue, 12 Aug 2003 21:49:51 -0600 From: "Kenneth D. Merry" <ken@kdm.org> To: Chuck Tuffli <chuck_tuffli@agilent.com> Cc: freebsd-scsi@freebsd.org Subject: Re: problem running scsi_target Message-ID: <20030813034951.GA91644@panzer.kdm.org> In-Reply-To: <20030813011206.GC2564@cre85086tuf.rose.agilent.com> References: <20030813000620.GA2564@cre85086tuf.rose.agilent.com> <20030813003357.GA90771@panzer.kdm.org> <20030813011206.GC2564@cre85086tuf.rose.agilent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 12, 2003 at 18:12:07 -0700, Chuck Tuffli wrote:
> On Tue, Aug 12, 2003 at 06:33:57PM -0600, Kenneth D. Merry wrote:
> [snip]
> > One thing I found, at least when connecting two Qlogic boards point to
> > point, is that they'll typically negotiate which target ID they're using.
> >
> > In short, if target 1 isn't working for you, try target 0 instead. (If
> > you've got the board hooked up to a switch, I'm not sure what will happen
> > as far as IDs go.)
>
> I do have this hooked up to a switch and 0:0:0 doesn't seem to work
> either. I just tried hooking this up to a private loop and get a
> different result
>
> fluffy# scsi_target -d 0:0:0 ./test_file
> scsi_target: aio support tested ok
> scsi_target: sending ccb (0x4)
> scsi_target: sending ccb (0x332)
> ...
> scsi_target: sending ccb (0x334)
> scsi_target: main loop beginning
>
> and there it hangs. camcontrol makes it look like the right thing is
> trying to happen
>
> fluffy# camcontrol devlist -v
> scbus0 on isp0 bus 0:
> < > at scbus0 target 0 lun 0 (targ0)
> < > at scbus0 target -1 lun -1 (targbh0)
> scbus-1 on xpt0 bus 0:
> < > at scbus-1 target -1 lun -1 (xpt0)
>
> The isp relavant portion of dmsg
>
> isp0: <Qlogic ISP 2200 PCI FC-AL Adapter> port 0x3000-0x30ff mem 0xfc204000-0xfc204fff irq 11 at device 1.0 on pci3
> isp0: Mbox Command Async (0x4000) with no waiters
> (noperiph:isp0:0:0:0): (xpt0:isp0:0:0:0): debugging flags now 20
> (targ0:isp0:0:0:0): write - uio_resid 4
> (targ0:isp0:0:0:0): Sending inline ccb 0x4 (0xbfbff99c)
> (targ0:isp0:0:0:0): getccb 0xc24ec900
> (targ0:isp0:0:0:0): sendccb 0xc24ec900
> (targ0:isp0:0:0:0): targreturnccb 0xc24ec900
> (targ0:isp0:0:0:0): write - uio_resid 4
> (targ0:isp0:0:0:0): getccb 0xc24ec900
Well, what initiator are you using?
One thing I found is that the scsi_target(8) code doesn't entirely play
well with the isp(4) driver.
I had to make some tweaks to get things working more or less okay, at least
with tagged queueing turned on:
- enable autosense. Fibre channel, and packetized parallel SCSI, do
autosense, but it is disabled by default. Go into scsi_cmds.c, and in
tcmd_sense(), uncomment the code after if (ctio != NULL) { ... that
fills in the sense buffer and sets the CAM_SEND_SENSE command.
- go into scsi_target.h and increase the value of MAX_INITIATORS to 256
instead of 16. I ended up running out of CCBs otherwise, at least with
tagged queueing turned on. (I made some other tweaks to it -- fake
ramdisk support -- that may have caused that problem, though.)
Anyway, the autosense thing is definitely one thing that you'll need to
tweak in order for it to work right with Fibre channel.
You can try increasing the number of initiators if it looks like you're
running out of CCBs.
Also, I found that if you use Linux as the initiator, with Qlogic's driver,
scsi_target(8) has problems when it gets the report luns command. I didn't
have enough time when I was messing with it to figure out why. It should
have just rejected the command, but that didn't seem to be happening. (It
could also have had something to do with my hacks to take out the aio
backend and do a fake ramdisk.)
FreeBSD works fine as an initiator, and as a bonus, rescanning works a lot
better. :)
Ken
--
Kenneth Merry
ken@kdm.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030813034951.GA91644>