Date: Sat, 28 Sep 2013 00:43:41 -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: <20130928064341.GA36807@nargothrond.kdm.org> In-Reply-To: <20130925194313.GA82349@nargothrond.kdm.org> References: <20130925035051.GA50458@FreeBSD.org> <20130925194313.GA82349@nargothrond.kdm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Sep 25, 2013 at 13:43:13 -0600, Kenneth D. Merry wrote: > 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. I have confirmed that was the problem, at least for me, on stable/9. I can create file-backed LUNs and export them via an 8Gb Qlogic FC card and it works fine. I ran into another bug (ctladm dumpooa causes a panic) in stable/9 that was due to something I didn't MFC. I just merged that fix as well. So if you update to the latest stable/9, it should work okay. Unfortunately this means that CTL is going to be broken in 9.2. I emailed RE; we'll see whether they want to merge the fixes or write it up in the errata. Ken -- Kenneth Merry ken@FreeBSD.ORG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130928064341.GA36807>