From: Andreas Hartmann <andihartmann@freenet.de>
To: Joerg Roedel <joro@8bytes.org>, Mikulas Patocka <mpatocka@redhat.com>
Cc: Andreas Hartmann <andihartmann@freenet.de>,
iommu@lists.linux-foundation.org, Leo Duran <leo.duran@amd.com>,
Christoph Hellwig <hch@lst.de>,
device-mapper development <dm-devel@redhat.com>,
Milan Broz <mbroz@redhat.com>, Jens Axboe <axboe@fb.com>,
linux-pci <linux-pci@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [dm-devel] AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
Date: Wed, 30 Sep 2015 16:52:47 +0200 [thread overview]
Message-ID: <560BF73F.8000008@maya.org> (raw)
In-Reply-To: <20150929162042.GR3036@8bytes.org>
On 09/29/2015 at 06:20 PM, Joerg Roedel wrote:
> On Tue, Sep 29, 2015 at 11:58:10AM -0400, Mikulas Patocka wrote:
>> On Tue, 29 Sep 2015, Joerg Roedel wrote:
>> There was a patch (34b48db66e08ca1c1bc07cf305d672ac940268dc) that
>> increased default block request size. That patch triggers AMD-Vi page
>> faults. The bug may be in ATA driver, in ATA controller on in AMD-Vi
>> driver or hardware. I didn't see anything in that thread that proves that
>> the bug in not in AMD-Vi IOMMU.
>>
>> The bug probably existed even before kernel 3.19, but it was masked by the
>> fact that I/O request size was artifically capped. Bisecting probably
>> won't find it, as it may have existed since ever.
>
> Okay, I see. But as long as the request-size is not bigger than 128MB
> (the biggest chunk the AMD IOMMU driver can map at once), I don't see
> how the IOMMU driver could be at fault.
>
> Which ATA driver is in use when this happens and are there instructions
> on how to reproduce the issue?
>
> Alternativly someone who can reproduce it should trace the calls to
> __map_single and __unmap_single in the AMD IOMMU driver to find out
> whether the addresses which the faults happen on are really mapped, or
> at least requested from the AMD IOMMU driver.
How can I trace it?
Thanks,
Andreas
WARNING: multiple messages have this Message-ID (diff)
From: Andreas Hartmann <andihartmann-KuiJ5kEpwI6ELgA04lAiVw@public.gmane.org>
To: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>,
Mikulas Patocka
<mpatocka-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: device-mapper development
<dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-pci <linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
Jens Axboe <axboe-b10kYP2dOMg@public.gmane.org>,
Andreas Hartmann
<andihartmann-KuiJ5kEpwI6ELgA04lAiVw@public.gmane.org>,
Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
Christoph Hellwig <hch-jcswGhMUV9g@public.gmane.org>,
Milan Broz <mbroz-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: [dm-devel] AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0
Date: Wed, 30 Sep 2015 16:52:47 +0200 [thread overview]
Message-ID: <560BF73F.8000008@maya.org> (raw)
In-Reply-To: <20150929162042.GR3036-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
On 09/29/2015 at 06:20 PM, Joerg Roedel wrote:
> On Tue, Sep 29, 2015 at 11:58:10AM -0400, Mikulas Patocka wrote:
>> On Tue, 29 Sep 2015, Joerg Roedel wrote:
>> There was a patch (34b48db66e08ca1c1bc07cf305d672ac940268dc) that
>> increased default block request size. That patch triggers AMD-Vi page
>> faults. The bug may be in ATA driver, in ATA controller on in AMD-Vi
>> driver or hardware. I didn't see anything in that thread that proves that
>> the bug in not in AMD-Vi IOMMU.
>>
>> The bug probably existed even before kernel 3.19, but it was masked by the
>> fact that I/O request size was artifically capped. Bisecting probably
>> won't find it, as it may have existed since ever.
>
> Okay, I see. But as long as the request-size is not bigger than 128MB
> (the biggest chunk the AMD IOMMU driver can map at once), I don't see
> how the IOMMU driver could be at fault.
>
> Which ATA driver is in use when this happens and are there instructions
> on how to reproduce the issue?
>
> Alternativly someone who can reproduce it should trace the calls to
> __map_single and __unmap_single in the AMD IOMMU driver to find out
> whether the addresses which the faults happen on are really mapped, or
> at least requested from the AMD IOMMU driver.
How can I trace it?
Thanks,
Andreas
next prev parent reply other threads:[~2015-09-30 14:55 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-28 17:40 AMD-Vi IO_PAGE_FAULTs and ata3.00: failed command: READ FPDMA QUEUED errors since Linux 4.0 Andreas Hartmann
2015-07-28 17:50 ` Mike Snitzer
2015-07-28 18:20 ` Andreas Hartmann
2015-07-28 18:58 ` Mike Snitzer
2015-07-28 19:23 ` Andreas Hartmann
2015-07-28 19:31 ` Mike Snitzer
2015-07-28 20:08 ` Andreas Hartmann
2015-07-28 21:24 ` Mike Snitzer
2015-07-29 6:17 ` [dm-devel] " Ondrej Kozina
2015-07-29 6:41 ` Milan Broz
2015-07-29 17:23 ` Andreas Hartmann
2015-07-30 20:30 ` Andreas Hartmann
2015-07-31 7:23 ` Milan Broz
2015-07-31 7:55 ` Andreas Hartmann
2015-07-31 8:15 ` Andreas Hartmann
2015-07-31 8:28 ` Milan Broz
2015-07-29 10:37 ` Milan Broz
2015-07-28 18:56 ` Andreas Hartmann
2015-07-28 19:29 ` Mike Snitzer
2015-08-01 14:20 ` [dm-devel] " Andreas Hartmann
2015-08-02 13:38 ` Andreas Hartmann
2015-08-02 17:57 ` Mikulas Patocka
2015-08-02 18:48 ` Andreas Hartmann
2015-08-02 18:48 ` Andreas Hartmann
2015-08-03 8:12 ` Joerg Roedel
2015-08-04 14:47 ` Mike Snitzer
2015-08-04 16:10 ` Jeff Moyer
[not found] ` <x4937zzm3uc.fsf-RRHT56Q3PSP4kTEheFKJxxDDeQx5vsVwAInAS/Ez/D0@public.gmane.org>
2015-08-04 18:11 ` Andreas Hartmann
2015-08-04 18:11 ` Andreas Hartmann
2015-08-07 6:04 ` Andreas Hartmann
2015-09-20 6:50 ` [dm-devel] " Andreas Hartmann
2015-09-20 6:50 ` Andreas Hartmann
2015-09-29 15:21 ` Joerg Roedel
2015-09-29 15:21 ` Joerg Roedel
2015-09-29 15:58 ` Mikulas Patocka
2015-09-29 15:58 ` Mikulas Patocka
2015-09-29 16:20 ` Joerg Roedel
2015-09-30 14:52 ` Andreas Hartmann [this message]
2015-09-30 14:52 ` Andreas Hartmann
2015-10-06 10:13 ` Joerg Roedel
2015-10-06 18:37 ` Andreas Hartmann
2015-10-06 18:37 ` Andreas Hartmann
[not found] ` <56141507.7040103-YKS6W9RDU/w@public.gmane.org>
2015-10-07 2:57 ` Andreas Hartmann
2015-10-07 16:10 ` Joerg Roedel
2015-10-07 16:10 ` Joerg Roedel
2015-10-07 16:52 ` Andreas Hartmann
2015-10-07 16:52 ` Andreas Hartmann
2015-10-08 16:39 ` Joerg Roedel
2015-10-08 18:21 ` Andreas Hartmann
2015-10-08 18:21 ` Andreas Hartmann
2015-10-08 19:52 ` Andreas Hartmann
2015-10-08 19:52 ` Andreas Hartmann
2015-10-09 5:20 ` Andreas Hartmann
2015-10-09 5:20 ` Andreas Hartmann
2015-10-09 9:15 ` Andreas Hartmann
2015-10-09 9:15 ` Andreas Hartmann
2015-10-09 14:59 ` Joerg Roedel
2015-10-09 14:59 ` Joerg Roedel
2015-10-09 17:46 ` Andreas Hartmann
2015-10-09 17:46 ` Andreas Hartmann
2015-10-11 12:23 ` Andreas Hartmann
2015-10-11 12:23 ` Andreas Hartmann
2015-10-12 12:07 ` Andreas Hartmann
2015-10-12 12:34 ` Mikulas Patocka
2015-10-07 15:40 ` Joerg Roedel
2015-10-07 17:02 ` Andreas Hartmann
2015-10-08 17:30 ` Joerg Roedel
2015-10-08 18:59 ` Andreas Hartmann
2015-10-08 18:59 ` Andreas Hartmann
2015-10-08 19:47 ` Andreas Hartmann
2015-10-08 19:47 ` Andreas Hartmann
2015-10-09 10:40 ` Joerg Roedel
2015-10-09 14:45 ` [PATCH] iommu/amd: Fix NULL pointer deref on device detach " Joerg Roedel
2015-10-09 14:45 ` Joerg Roedel
2015-10-09 14:45 ` Joerg Roedel
2015-10-09 17:42 ` Andreas Hartmann
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=560BF73F.8000008@maya.org \
--to=andihartmann@freenet.de \
--cc=axboe@fb.com \
--cc=dm-devel@redhat.com \
--cc=hch@lst.de \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=leo.duran@amd.com \
--cc=linux-pci@vger.kernel.org \
--cc=mbroz@redhat.com \
--cc=mpatocka@redhat.com \
--cc=torvalds@linux-foundation.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.