Date: Wed, 25 Sep 2013 13:43:13 -0600 From: "Kenneth D. Merry" <ken@freebsd.org> To: John <jwd@freebsd.org> Cc: FreeBSD-SCSI <freebsd-scsi@freebsd.org> Subject: Re: panic with CTL/FC at r251897 and beyond Message-ID: <20130925194313.GA82349@nargothrond.kdm.org> In-Reply-To: <20130925035051.GA50458@FreeBSD.org> References: <20130925035051.GA50458@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
On Wed, Sep 25, 2013 at 03:50:51 +0000, John wrote:
> Hi Folks,
>
> I've slowly been chasing down a panic with 9-stable and I've
> gotten to the point where the large mfc commits of r251897 and
> r251874 by Scott seem to be the culprit. I posted some info
> about this a few weeks back.
>
> The last working commit (involving cam) is r251852 by Alexander.
> This is the last commit where I can create and export a lun via
> FC and have the client use it.
Hmm, that's not good!
> The problem I see is in cam/ctl/scsi_ctl.c:ctlfedone() at
> the end of the XPT_CONT_TARGET_IO: switch label:
>
> /*
> * Release the CTIO. The ATIO will be sent back
> * down to the SIM once we send status.
> */
> softc->ccbs_freed++;
> xpt_release_ccb(done_ccb);
>
> /* Call the backend move done callback */
> io->scsiio.be_move_done(io);
>
> be_move_done is null so the code branches to 0
>
>
> Before I start trying to figure out the large number of
> changes in the above 2 commits (a pair of mass mfc's) I was
> hoping someone might have an idea of what is wrong and could
> provide some pointers. I'd also be curious to know if anyone
> is successfully using a recent 9-stable with CTL/FC and if
> so, how they have it configured.
>
> Fbsd-10 works correctly on the same hardware also.
>
> I can provide ssh access and serial console debugging
> if needed.
Try the attached patch. I neglected to MFC it, and you'll certainly have
problems without it with the block backend.
The ramdisk backend should work okay without this patch, because it doesn't
use S/G lists by default.
It's possible that the be_move_done() pointer is getting overwritten by a
DMA.
Ken
--
Kenneth Merry
ken@FreeBSD.ORG
--G4iJoqBmSsgzjUCe
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="scsi_ctl.c.249028.txt"
==== //depot/users/kenm/FreeBSD-stable/9/sys/cam/ctl/scsi_ctl.c#6 - /usr/home/kenm/perforce4/kenm/FreeBSD-stable/9/sys/cam/ctl/scsi_ctl.c ====
*** /tmp/tmp.38501.93 Wed Sep 25 13:33:36 2013
--- /usr/home/kenm/perforce4/kenm/FreeBSD-stable/9/sys/cam/ctl/scsi_ctl.c Wed Sep 25 13:33:20 2013
***************
*** 916,922 ****
if (io->io_hdr.flags & CTL_FLAG_BUS_ADDR)
flags |= CAM_DATA_SG_PADDR;
else
! flags &= ~CAM_DATA_SG;
data_ptr = (uint8_t *)cam_sglist;
dxfer_len = io->scsiio.kern_data_len;
} else {
--- 916,922 ----
if (io->io_hdr.flags & CTL_FLAG_BUS_ADDR)
flags |= CAM_DATA_SG_PADDR;
else
! flags |= CAM_DATA_SG;
data_ptr = (uint8_t *)cam_sglist;
dxfer_len = io->scsiio.kern_data_len;
} else {
***************
*** 938,943 ****
--- 938,947 ----
data_ptr = sglist[*ti].addr;
dxfer_len = sglist[*ti].len;
csio->sglist_cnt = 0;
+ if (io->io_hdr.flags & CTL_FLAG_BUS_ADDR)
+ flags |= CAM_DATA_PADDR;
+ else
+ flags |= CAM_DATA_VADDR;
cmd_info->flags |= CTLFE_CMD_PIECEWISE;
(*ti)++;
}
--G4iJoqBmSsgzjUCe--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130925194313.GA82349>