From patchwork Thu Jan 6 10:38:20 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Ferre X-Patchwork-Id: 77701 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from canuck.infradead.org (canuck.infradead.org [134.117.69.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id E9DBCB708B for ; Thu, 6 Jan 2011 21:41:52 +1100 (EST) Received: from localhost ([127.0.0.1] helo=canuck.infradead.org) by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1PanF6-0000Uj-4I; Thu, 06 Jan 2011 10:38:52 +0000 Received: from mail.atmel.fr ([81.80.104.162] helo=atmel-es2.atmel.fr) by canuck.infradead.org with esmtp (Exim 4.72 #1 (Red Hat Linux)) id 1PanF1-0000Ta-Mu; Thu, 06 Jan 2011 10:38:49 +0000 Received: from meyreuil.atmel.fr (meyreuil [10.159.254.132]) by atmel-es2.atmel.fr (8.11.7p1+Sun/8.11.6) with ESMTP id p06AcLZ08405; Thu, 6 Jan 2011 11:38:21 +0100 (MET) Received: from [10.159.245.112] ([10.159.245.112]) by meyreuil.atmel.fr (8.11.7p1+Sun/8.11.7) with ESMTP id p06AcLj23960; Thu, 6 Jan 2011 11:38:21 +0100 (MET) Message-ID: <4D259B9C.6060409@atmel.com> Date: Thu, 06 Jan 2011 11:38:20 +0100 From: Nicolas Ferre Organization: atmel User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Russell King - ARM Linux , linux-mtd Subject: Re: Hit BUG_ON in dma-mapping.c:425 References: <4D24A108.2080609@atmel.com> <20110105165551.GE8638@n2100.arm.linux.org.uk> In-Reply-To: <20110105165551.GE8638@n2100.arm.linux.org.uk> X-CRM114-Version: 20090807-BlameThorstenAndJenny ( TRE 0.7.6 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20110106_053848_523514_26C8A289 X-CRM114-Status: GOOD ( 16.00 ) X-Spam-Score: 0.0 (/) X-Spam-Report: SpamAssassin version 3.3.1 on canuck.infradead.org summary: Content analysis details: (0.0 points) pts rule name description ---- ---------------------- -------------------------------------------------- Cc: Hong XU , Patrice VILCHEZ , Linux Kernel list , Jean-Christophe PLAGNIOL-VILLARD , Andrew Victor , "'linux-arm-kernel@lists.infradead.org'" X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.12 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 (I include MTD mailing-list now) Le 05/01/2011 17:55, Russell King - ARM Linux : > On Wed, Jan 05, 2011 at 05:49:12PM +0100, Nicolas Ferre wrote: >> Hi, >> >> While running mtd_stresstest on a dataflash (atmel_spi >> + mtd_dataflash drivers) I hit the BUG_ON directive that >> is at the beginning of ___dma_single_cpu_to_dev() function. >> This function is called from the SPI driver that do a >> dma_map_single() before DMA operations on the buffer >> transmitted from upper layers. >> >> It seems that this address is above "high_memory" limit because >> it is allocated by vmalloc (in mtd_stresstest.c:285)... > > Well, its telling you is that you're not allowed to DMA to vmalloc > addresses. Whether that's the fault of the map driver or not is a > question for mtd folk. So you mean that those vmalloc calls should be changed to kmalloc in MTD like this: I also discovered the same issue while trying to write with "dd" on /dev/mtdblockx Same vmalloc'ed memory seems to be used in mtdblock_writesect(): mtdblk->cache_data = vmalloc(mtdblk->mbd.mtd->erasesize); I know that using "dd" on a block device is not the common case but it should work instead of not being able to transmit buffer with DMA... So what it implies to switch this to kmalloc? Is it regression-free to do this? Best regards, --- a/drivers/mtd/tests/mtd_stresstest.c +++ b/drivers/mtd/tests/mtd_stresstest.c @@ -26,7 +26,6 @@ #include #include #include -#include #define PRINT_PREF KERN_INFO "mtd_stresstest: " @@ -281,8 +280,8 @@ static int __init mtd_stresstest_init(void) bufsize = mtd->erasesize * 2; err = -ENOMEM; - readbuf = vmalloc(bufsize); - writebuf = vmalloc(bufsize); + readbuf = kmalloc(bufsize, GFP_KERNEL); + writebuf = kmalloc(bufsize, GFP_KERNEL); offsets = kmalloc(ebcnt * sizeof(int), GFP_KERNEL); if (!readbuf || !writebuf || !offsets) { printk(PRINT_PREF "error: cannot allocate memory\n"); @@ -313,8 +312,8 @@ static int __init mtd_stresstest_init(void) out: kfree(offsets); kfree(bbt); - vfree(writebuf); - vfree(readbuf); + kfree(writebuf); + kfree(readbuf); put_mtd_device(mtd); if (err) printk(PRINT_PREF "error %d occurred\n", err);