Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754096AbcKVIpa (ORCPT ); Tue, 22 Nov 2016 03:45:30 -0500 Received: from 8bytes.org ([81.169.241.247]:36498 "EHLO theia.8bytes.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752001AbcKVIp3 (ORCPT ); Tue, 22 Nov 2016 03:45:29 -0500 Date: Tue, 22 Nov 2016 09:45:22 +0100 From: Joerg Roedel To: Mark Hounschell Cc: iommu@lists.linux-foundation.org, Linux-kernel Subject: Re: BUG at drivers/iommu/amd_iommu.c:1436! Message-ID: <20161122084522.GF2078@8bytes.org> References: <838275de-6cac-93d8-ca04-54b06a24b3d4@compro.net> <20161117214141.GC2078@8bytes.org> <20161117220045.GD2078@8bytes.org> <20161121153250.GE2078@8bytes.org> <4f6afa52-9634-79f4-01af-1ae047aa83f7@compro.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4f6afa52-9634-79f4-01af-1ae047aa83f7@compro.net> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1193 Lines: 27 On Mon, Nov 21, 2016 at 04:47:59PM -0500, Mark Hounschell wrote: > OK, I did get this message before the reported BUG message. > > gpiohsd gpiohsd: DMA-API: device driver tries to free DMA memory it has not allocated [device address=0xffffffffffee8000] [size=8192 bytes] > > But I've verified that the dma_addr_t that I get for the alloc, and > also use for the free is 0x00000000ffee8000 in this case? Is device > "address=0xffffffffffee8000" in that message a bug in the message or > do we have a sign extended address problem? It seems strange to me, > I've never seen a dma_addr_t given, when using the iommu, that > high. In the past I've seen them as usually 0x00xxxxxx? > > I have also verified that simply changing from > pci_alloc/free_consistent to the newer DMA API fixes my issue and I > get no such messages. Yes, this looks like a sign-extension bug somewhere. But its not in the amd-iommu driver, because dma-debug also sees it. And from what I can tell the dma-api interface seems to be fine. It consistently uses dma_addr_t to pass these values around. Where can I find the source of the failing code? I need exactly the code version that triggers the problem. Joerg