From patchwork Thu Apr 5 12:27:41 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vinod Koul X-Patchwork-Id: 150945 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from merlin.infradead.org (merlin.infradead.org [IPv6:2001:4978:20e::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id D56C0B7039 for ; Thu, 5 Apr 2012 22:27:08 +1000 (EST) Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SFllR-00037i-Sm; Thu, 05 Apr 2012 12:26:09 +0000 Received: from mga09.intel.com ([134.134.136.24]) by merlin.infradead.org with esmtp (Exim 4.76 #1 (Red Hat Linux)) id 1SFllO-00037R-N8; Thu, 05 Apr 2012 12:26:07 +0000 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 05 Apr 2012 05:26:04 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.67,352,1309762800"; d="scan'208";a="125621553" Received: from vkoul-udesk3.iind.intel.com (HELO [10.223.85.32]) ([10.223.85.32]) by orsmga001.jf.intel.com with ESMTP; 05 Apr 2012 05:26:02 -0700 Subject: Re: Using GPMI-NAND driver on iMX28 using 3.4-rc1? From: Vinod Koul To: Sam Gandhi In-Reply-To: References: <20120404070157.GB24930@pengutronix.de> <20120404183314.GF17187@pengutronix.de> <4F7D3DB8.6080009@freescale.com> Date: Thu, 05 Apr 2012 17:57:41 +0530 Message-ID: <1333628861.31825.22.camel@vkoul-udesk3> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 X-Spam-Note: CRM114 invocation failed X-Spam-Score: -6.9 (------) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-6.9 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [134.134.136.24 listed in list.dnswl.org] -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: Russell King - ARM Linux , Wolfram Sang , Huang Shijie , linux-mtd@lists.infradead.org, "linux-arm-kernel@lists.infradead.org" , Fabio Estevam , Shawn Guo X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-mtd-bounces@lists.infradead.org Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org On Thu, 2012-04-05 at 05:03 -0700, Sam Gandhi wrote: > 2012/4/4 Huang Shijie : > > Hi All: > >> On Wed, Apr 4, 2012 at 7:07 PM, Sam Gandhi wrote: > >> > >>> I reverted that commit and I still see following error! > >> Huang, > >> > >> Are you able to use gpmi on mx28 running 3.4-rc1? > >> > > I also meet the same problem today. > > > > > >>> flash_erase /dev/mtd1 0 0 > >>> Erasing 1------------[ cut here ]------------ > >>> kernel BUG at /home/sam/linux/drivers/dma/dmaengine.h:53! > > the mxs-dma has added some patches about the cookie. > > The bug is in the dmaengine.h. > > > > So let more people know this bug. > > > > BR > > Huang Shijie > > > > > FWIW, Just a data point. > > I coverted BUG_ON in dmaengine.h to printk as shown below. With this > change I was able to format nand, create UBI partition. I have been > running UBI torture test called integck on my board that does lot of > I/O, mounting/unmounting of filesystem for close to 8 hour now without > crash. But I do see those printks. I haven't followed logic of > tx->cookie well enough to figure out what the appropriate change > should be. Note this is with commit > 00292bbf769620dea923dbd906afd88955f7ea19 reverted in my tree. > > Cookie 0 completed 102118268 DMA_MIN 1 > Cookie 0 completed 102120401 DMA_MIN 1 > Cookie 0 completed 102237726 DMA_MIN 1 > > git diff drivers/dma/dmaengine.h > diff --git a/drivers/dma/dmaengine.h b/drivers/dma/dmaengine.h > index 17f983a..3d10a70 100644 > --- a/drivers/dma/dmaengine.h > +++ b/drivers/dma/dmaengine.h > @@ -50,7 +50,11 @@ static inline dma_cookie_t dma_cookie_assign(struct > dma_async_tx_descriptor *tx) > */ > static inline void dma_cookie_complete(struct dma_async_tx_descriptor *tx) > { > - BUG_ON(tx->cookie < DMA_MIN_COOKIE); > + if ( tx->cookie < DMA_MIN_COOKIE) > + printk(KERN_ERR "Cookie %d, completed %d DMA_MIN %d > ",tx->cookie, > + tx->chan->completed_cookie, > + DMA_MIN_COOKIE); > + /* BUG_ON(tx->cookie < DMA_MIN_COOKIE); */ > tx->chan->completed_cookie = tx->cookie; > tx->cookie = 0; > } This means you are trying to mark a cookie complete when it is already marked so!, hence dmaengine screams. The bug is is mxs-dma. Let me know if below fixes it (assuming you are not using cyclic API, that would need fixup as well) if (direction == DMA_TRANS_NONE) { diff --git a/drivers/dma/mxs-dma.c b/drivers/dma/mxs-dma.c index c81ef7e..5ddd84e 100644 --- a/drivers/dma/mxs-dma.c +++ b/drivers/dma/mxs-dma.c @@ -399,6 +399,10 @@ static struct dma_async_tx_descriptor *mxs_dma_prep_slave_sg( ccw->bits &= ~CCW_DEC_SEM; } else { idx = 0; + /* assign cookie here, + * hopefully for above case we dont need it + */ + dma_cookie_assign(&mxs_chan->desc); }