From owner-freebsd-scsi@FreeBSD.ORG Sat Sep 28 06:43:43 2013 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2E09B8EA; Sat, 28 Sep 2013 06:43:43 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CE46E28DE; Sat, 28 Sep 2013 06:43:42 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id r8S6hfZO037500; Sat, 28 Sep 2013 00:43:41 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id r8S6hfL1037499; Sat, 28 Sep 2013 00:43:41 -0600 (MDT) (envelope-from ken) Date: Sat, 28 Sep 2013 00:43:41 -0600 From: "Kenneth D. Merry" To: John Subject: Re: panic with CTL/FC at r251897 and beyond Message-ID: <20130928064341.GA36807@nargothrond.kdm.org> References: <20130925035051.GA50458@FreeBSD.org> <20130925194313.GA82349@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130925194313.GA82349@nargothrond.kdm.org> User-Agent: Mutt/1.4.2i Cc: FreeBSD-SCSI X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 06:43:43 -0000 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