Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932386Ab1CCRzM (ORCPT ); Thu, 3 Mar 2011 12:55:12 -0500 Received: from ovro.ovro.caltech.edu ([192.100.16.2]:38985 "EHLO ovro.ovro.caltech.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932230Ab1CCRzI (ORCPT ); Thu, 3 Mar 2011 12:55:08 -0500 From: "Ira W. Snyder" To: linuxppc-dev@lists.ozlabs.org Cc: linux-kernel@vger.kernel.org, leoli@freescale.com, dan.j.williams@intel.com, "Ira W. Snyder" Subject: [PATCH v3 0/9] fsldma: lockup fixes Date: Thu, 3 Mar 2011 09:54:52 -0800 Message-Id: <1299174901-16762-1-git-send-email-iws@ovro.caltech.edu> X-Mailer: git-send-email 1.7.3.4 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (ovro.ovro.caltech.edu); Thu, 03 Mar 2011 09:55:08 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2764 Lines: 66 Hello everyone, I've been chasing random infrequent controller lockups in the fsldma driver for a long time. I finally managed to find the problem and fix it. I'm not quite sure about the exact sequence of events which causes the race condition, but it is related to using the hardware registers to track the controller state. See the patch changelogs for more detail. The problems were quickly found by turning on DMAPOOL_DEBUG inside mm/dmapool.c. This poisons memory allocated with the dmapool API. With dmapool poisoning turned on, the dmatest driver would start producing failures within a few seconds. After this patchset has been applied, I have run several iterations of the 10 threads per channel, 100000 iterations per thread test without any problems. I have also tested it with the CARMA drivers (posted at linuxppc-dev previously), which make use of the external control features. While making the previous changes, I noticed that the fsldma driver does not respect the automatic DMA unmapping of src and dst buffers. I have added support for this feature. This also required a fix to dmatest, which was sending incorrect flags. The "support async_tx dependencies" patch could be split apart from the automatic unmapping patch if it is desirable. They both touch the same piece of code, so I thought it was ok to combine them. Let me know. I would really like to see this go into 2.6.39. I think we can get it reviewed before then. :) Much thanks goes to Felix Radensky for testing on a P2020 (85xx DMA IP core). I wouldn't have been able to track down the problems on 85xx without his dilligent testing. v2 -> v3: - use chan_dbg() and chan_err() macros for channel printk v1 -> v2: - reordered patches (dmatest change is first now) - fix problems on 85xx controller - only set correct bits for 83xx in dma_halt() Ira W. Snyder (9): dmatest: fix automatic buffer unmap type fsldma: move related helper functions near each other fsldma: use channel name in printk output fsldma: improve link descriptor debugging fsldma: minor codingstyle and consistency fixes fsldma: fix controller lockups fsldma: support async_tx dependencies and automatic unmapping fsldma: reduce locking during descriptor cleanup fsldma: make halt behave nicely on all supported controllers drivers/dma/dmatest.c | 7 +- drivers/dma/fsldma.c | 551 +++++++++++++++++++++++++++---------------------- drivers/dma/fsldma.h | 6 +- 3 files changed, 311 insertions(+), 253 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/