All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
To: Mark Hounschell <markh-n2QNKt385d+sTnJN9+BGXg@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Linux-kernel
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: BUG at drivers/iommu/amd_iommu.c:1436!
Date: Tue, 22 Nov 2016 09:45:22 +0100	[thread overview]
Message-ID: <20161122084522.GF2078@8bytes.org> (raw)
In-Reply-To: <4f6afa52-9634-79f4-01af-1ae047aa83f7-n2QNKt385d+sTnJN9+BGXg@public.gmane.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: Joerg Roedel <joro@8bytes.org>
To: Mark Hounschell <markh@compro.net>
Cc: iommu@lists.linux-foundation.org,
	Linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: BUG at drivers/iommu/amd_iommu.c:1436!
Date: Tue, 22 Nov 2016 09:45:22 +0100	[thread overview]
Message-ID: <20161122084522.GF2078@8bytes.org> (raw)
In-Reply-To: <4f6afa52-9634-79f4-01af-1ae047aa83f7@compro.net>

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

  parent reply	other threads:[~2016-11-22  8:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17 19:13 BUG at drivers/iommu/amd_iommu.c:1436! Mark Hounschell
2016-11-17 19:13 ` Mark Hounschell
     [not found] ` <838275de-6cac-93d8-ca04-54b06a24b3d4-n2QNKt385d+sTnJN9+BGXg@public.gmane.org>
2016-11-17 21:41   ` Joerg Roedel
2016-11-17 21:41     ` Joerg Roedel
     [not found]     ` <20161117214141.GC2078-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2016-11-17 21:53       ` Mark Hounschell
2016-11-17 21:53         ` Mark Hounschell
     [not found]         ` <f4ababc2-64bf-fd0e-1d18-cb5963d23eb1-n2QNKt385d+sTnJN9+BGXg@public.gmane.org>
2016-11-17 22:00           ` Joerg Roedel
2016-11-17 22:00             ` Joerg Roedel
     [not found]             ` <20161117220045.GD2078-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2016-11-18 14:04               ` Mark Hounschell
2016-11-18 14:04                 ` Mark Hounschell
     [not found]                 ` <b8260bfd-55c9-c029-1af1-e1ccc719dd3a-n2QNKt385d+sTnJN9+BGXg@public.gmane.org>
2016-11-21 15:32                   ` Joerg Roedel
2016-11-21 15:32                     ` Joerg Roedel
     [not found]                     ` <20161121153250.GE2078-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2016-11-21 21:47                       ` Mark Hounschell
2016-11-21 21:47                         ` Mark Hounschell
     [not found]                         ` <4f6afa52-9634-79f4-01af-1ae047aa83f7-n2QNKt385d+sTnJN9+BGXg@public.gmane.org>
2016-11-22  8:45                           ` Joerg Roedel [this message]
2016-11-22  8:45                             ` Joerg Roedel
     [not found]                             ` <20161122084522.GF2078-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2016-11-22 19:53                               ` Mark Hounschell
2016-11-22 19:53                                 ` Mark Hounschell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161122084522.GF2078@8bytes.org \
    --to=joro-zlv9swrftaidnm+yrofe0a@public.gmane.org \
    --cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=markh-n2QNKt385d+sTnJN9+BGXg@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.