From patchwork Fri Jan 9 16:19:30 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Joerg Roedel X-Patchwork-Id: 17528 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id DA6FB47506 for ; Sat, 10 Jan 2009 03:20:13 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752527AbZAIQTv (ORCPT ); Fri, 9 Jan 2009 11:19:51 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752458AbZAIQTt (ORCPT ); Fri, 9 Jan 2009 11:19:49 -0500 Received: from outbound-wa4.frontbridge.com ([216.32.181.16]:32087 "EHLO WA4EHSOBE002.bigfish.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752166AbZAIQTn (ORCPT ); Fri, 9 Jan 2009 11:19:43 -0500 Received: from mail23-wa4-R.bigfish.com (10.8.14.254) by WA4EHSOBE002.bigfish.com (10.8.40.22) with Microsoft SMTP Server id 8.1.291.1; Fri, 9 Jan 2009 16:19:42 +0000 Received: from mail23-wa4 (localhost.localdomain [127.0.0.1]) by mail23-wa4-R.bigfish.com (Postfix) with ESMTP id 858B113C8153; Fri, 9 Jan 2009 16:19:42 +0000 (UTC) X-BigFish: VPS-1(z5edJz936eQzzzzz32i43j68o) X-Spam-TCS-SCL: 7:0 X-FB-SS: 5, Received: by mail23-wa4 (MessageSwitch) id 1231517980377673_16522; Fri, 9 Jan 2009 16:19:40 +0000 (UCT) Received: from svlb1extmailp02.amd.com (unknown [139.95.251.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail23-wa4.bigfish.com (Postfix) with ESMTP id 4062419D0051; Fri, 9 Jan 2009 16:19:40 +0000 (UTC) Received: from svlb1twp01.amd.com ([139.95.250.34]) by svlb1extmailp02.amd.com (Switch-3.2.7/Switch-3.2.7) with ESMTP id n09GJTVv004096; Fri, 9 Jan 2009 08:19:34 -0800 X-WSS-ID: 0KD7PCL-03-IX9-01 Received: from SSVLEXBH2.amd.com (ssvlexbh2.amd.com [139.95.53.183]) by svlb1twp01.amd.com (Tumbleweed MailGate 3.5.1) with ESMTP id 28CCD884953; Fri, 9 Jan 2009 08:19:32 -0800 (PST) Received: from ssvlexmb2.amd.com ([139.95.53.7]) by SSVLEXBH2.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 08:19:38 -0800 Received: from SF30EXMB1.amd.com ([172.20.6.49]) by ssvlexmb2.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 08:19:38 -0800 Received: from lemmy.localdomain ([165.204.85.93]) by SF30EXMB1.amd.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Jan 2009 17:19:30 +0100 Received: by lemmy.localdomain (Postfix, from userid 41430) id CCE4E53C44; Fri, 9 Jan 2009 17:19:30 +0100 (CET) From: Joerg Roedel To: linux-kernel@vger.kernel.org CC: mingo@redhat.com, dwmw2@infradead.org, fujita.tomonori@lab.ntt.co.jp, netdev@vger.kernel.org, iommu@lists.linux-foundation.org, Joerg Roedel Subject: [PATCH 16/16] dma-debug: Documentation update Date: Fri, 9 Jan 2009 17:19:30 +0100 Message-ID: <1231517970-20288-17-git-send-email-joerg.roedel@amd.com> X-Mailer: git-send-email 1.5.6.4 In-Reply-To: <1231517970-20288-1-git-send-email-joerg.roedel@amd.com> References: <1231517970-20288-1-git-send-email-joerg.roedel@amd.com> X-OriginalArrivalTime: 09 Jan 2009 16:19:30.0904 (UTC) FILETIME=[0D258580:01C97276] MIME-Version: 1.0 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Impact: add documentation about DMA-API debugging to DMA-API.txt Signed-off-by: Joerg Roedel --- Documentation/DMA-API.txt | 117 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 117 insertions(+), 0 deletions(-) diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index b462bb1..e36e85a 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -610,3 +610,120 @@ size is the size (and should be a page-sized multiple). The return value will be either a pointer to the processor virtual address of the memory, or an error (via PTR_ERR()) if any part of the region is occupied. + +Part III - Debug drivers use of the DMA-API +------------------------------------------- + +The DMA-API as described above as some constraints. DMA addresses must be +released with the corresponding function with the same size for example. With +the advent of hardware IOMMUs it becomes more and more important that drivers +do not violate those constraints. In the worst case such a violation can +result in data corruption up to destroyed filesystems. + +To debug drivers and find bugs in the usage of the DMA-API checking code can +be compiled into the kernel which will tell the developer about those +violations. If your architecture supports it you can select the "Enable +debugging of DMA-API usage" option in your kernel configuration. Enabling this +option has a performance impact. Do not enable it in production kernels. + +If you boot the resulting kernel will contain code which does some bookkeeping +about what DMA memory was allocated for which device. If this code detects an +error it prints a warning message with some details into your kernel log. An +example warning message may look like this: + +------------[ cut here ]------------ +WARNING: at /data2/repos/linux.trees.git/lib/dma-debug.c:231 + check_unmap+0xab/0x3d9() +Hardware name: Toonie +bnx2 0000:01:00.0: DMA-API: device driver tries to free DMA + memory it has not allocated [device address=0x00000000011] +Modules linked in: +Pid: 0, comm: swapper Not tainted 2.6.28 #174 +Call Trace: + [] warn_slowpath+0xd3/0xf2 + [] ? find_usage_backwards+0xe2/0x116 + [] ? find_usage_backwards+0xe2/0x116 + [] ? usb_hcd_link_urb_to_ep+0x94/0xa0 + [] ? mark_lock+0x1c/0x364 + [] ? __lock_acquire+0xaec/0xb55 + [] ? mark_lock+0x1c/0x364 + [] ? get_hash_bucket+0x28/0x33 + [] ? _spin_lock_irqsave+0x69/0x75 + [] ? get_hash_bucket+0x28/0x33 + [] check_unmap+0xab/0x3d9 + [] ? trace_hardirqs_on_caller+0x108/0x14a + [] ? trace_hardirqs_on+0xd/0xf + [] debug_unmap_single+0x3e/0x40 + [] dma_unmap_single+0x3d/0x60 + [] pci_unmap_page+0x1c/0x1e + [] bnx2_poll_work+0x626/0x8cb + [] ? __lock_acquire+0xaec/0xb55 + [] ? run_posix_cpu_timers+0x49c/0x603 + [] ? run_posix_cpu_timers+0x39c/0x603 + [] ? mark_lock+0x1c/0x364 + [] ? __lock_acquire+0xaec/0xb55 + [] bnx2_poll_msix+0x33/0x81 + [] net_rx_action+0x8a/0x139 + [] __do_softirq+0x8b/0x147 + [] call_softirq+0x1c/0x34 + [] do_softirq+0x39/0x90 + [] irq_exit+0x4e/0x98 + [] do_IRQ+0x11f/0x135 + [] ret_from_intr+0x0/0xf + <4>---[ end trace 4339d58302097423 ]--- + +The driver developer can find the driver and the device including a stacktrace +of the DMA-API call which caused this warning. + +Per default only the first error will result in a warning message. All other +errors will only silently counted. This limitation exist to prevent the code +from flooding your kernel log. To support debugging a device driver this can +be disabled via debugfs. See the debugfs interface documentation below for +details. + +The debugfs directory for the DMA-API debugging code is called dma-api/. In +this directory the following files can currently be found: + + dma-api/all_errors This file contains a numeric value. If this + value is not equal to zero the debugging code + will print a warning for every error it finds + into the kernel log. Be carefull with this + option. It can easily flood your logs. + + dma-api/disabled This read-only file contains the character 'Y' + if the debugging code is disabled. This can + happen when it runs out of memory or if it was + disabled at boot time + + dma-api/error_count This file is read-only and shows the total + numbers of errors found. + + dma-api/num_errors The number in this file shows how many + warnings will be printed to the kernel log + before it stops. This number is initialized to + one at system boot and be set by writing into + this file + + dma-api/min_free_entries + This read-only file can be read to get the + minimum number of free dma_debug_entries the + allocator has ever seen. If this value goes + down to zero the code will disable itself + because it is not longer reliable. + + dma-api/num_free_entries + The current number of free dma_debug_entries + in the allocator. + +If you have this code compiled into your kernel it will be enabled by default. +If you want to boot without the bookkeeping anyway you can provide +'dma_debug=off' as a boot parameter. This will disable DMA-API debugging. +Notice that you can not enable it again at runtime. You have to reboot to do +so. + +When the code disables itself at runtime this is most likely because it ran +out of dma_debug_entries. These entries are preallocated at boot. The number +of preallocated entries is defined per architecture. If it is too low for you +boot with 'dma_debug_entries=' to overwrite the +architectural default. +