On Thu, 14 Jul 2016 00:52:02 +0300 (EEST)
Meelis Roos wrote:
> > >> Thanks. So device 00:1e.0 is a PCI-bridge which has some 32-bit
> > >> PCI-devices behind it. One of these devices tries to read address
> > >> 0xb000, which is blocked by the IOMMU and causes the fault seen in the
> > >> screen-
> >> Thanks. So device 00:1e.0 is a PCI-bridge which has some 32-bit
> >> PCI-devices behind it. One of these devices tries to read address
> >> 0xb000, which is blocked by the IOMMU and causes the fault seen in the
> >> screen-shot. The fault also causes a PCI-error which is then reported
> >> thr
Passing a NULL or uninitialized iova_domain into put_iova_domain
will currently crash the kernel when the unconfigured iova_domain
data members are accessed. To prevent this from occurring, this patch
adds a check to make sure that the domain is non-NULL and that the
domain granule is non-zero. The
Hi Nate,
On 13/07/16 17:41, Nate Watterson wrote:
> In the current dma-iommu implementation, the upper limit used when
> allocating iovas is based on the calling device's dma_mask without
> considering the potentially more restrictive iova limits established
> in iommu_dma_init_domain. To ensure t
tree: https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git x86/amd
head: a2c9b667b1c0e78d39f339a90fd6a2bd4a6ff8d8
commit: 0b1c8fa308906ad01928609ac04e486d34894052 [19/23] iommu/amd: Optimize
map_sg and unmap_sg
config: x86_64-randconfig-s4-07140059 (attached as .config)
compiler: gcc
In the current dma-iommu implementation, the upper limit used when
allocating iovas is based on the calling device's dma_mask without
considering the potentially more restrictive iova limits established
in iommu_dma_init_domain. To ensure that iovas are allocated within
the expected iova region, th
On 7/13/2016 10:48 AM, Alex Williamson wrote:
> On Wed, 13 Jul 2016 12:18:59 +0200
> Joerg Roedel wrote:
>
>> On Wed, Jul 13, 2016 at 12:58:24PM +0300, Meelis Roos wrote:
> Just got http://kodu.ut.ee/~mroos/4.6-dmar-fault2.png when playing with
> BIOS settings (disabling NUMA). It is t
On Wed, 13 Jul 2016 12:18:59 +0200
Joerg Roedel wrote:
> On Wed, Jul 13, 2016 at 12:58:24PM +0300, Meelis Roos wrote:
> > > > Just got http://kodu.ut.ee/~mroos/4.6-dmar-fault2.png when playing with
> > > > BIOS settings (disabling NUMA). It is the first time I see at least
> > > > some
> > > >
On Wed, 13 Jul 2016, Joerg Roedel wrote:
> On Wed, Jul 13, 2016 at 11:31:02AM +0300, Meelis Roos wrote:
> > > > Bisecting kernel configs shows that it's DMAR+IOMMU. When it is
> > > > activated, there is high probability of NMI-s in random places.
> > >
> > > Hmm, strange. But nothing could reall
In 'commit <55d940430ab9> ("iommu/vt-d: Get rid of domain->iommu_lock")',
the error handling path is changed a little, which makes the function
always return 0.
This path fixes this.
Signed-off-by: Wei Yang
---
drivers/iommu/intel-iommu.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Joerg Roedel
The default domain for a device might also be
identity-mapped. In this case the kernel would crash when
unity mappings are defined for the device. Fix that by
making sure the domain is a dma_ops domain.
Fixes: 0bb6e243d7fb ('iommu/amd: Support IOMMU_DOMAIN_DMA type allocation'
On Mon, Jul 04, 2016 at 09:01:18PM +0200, Heiner Kallweit wrote:
> Am 04.07.2016 um 13:46 schrieb Joerg Roedel:
> > On Wed, Jun 29, 2016 at 09:13:59PM +0200, Heiner Kallweit wrote:
> >> Ida handling can be much simplified by using the ida_simple_.. functions.
> >>
> >> This change also fixes the bu
On Tue, Jul 12, 2016 at 04:34:16PM +0100, Robin Murphy wrote:
> The boundary masks for block devices are tricky to track down through so
> many layers of indirection in the common frameworks, but there are a lot
> of 64K ones there. After some more impromptu digging into the subject
> I've finally
On Wed, Jul 13, 2016 at 12:58:24PM +0300, Meelis Roos wrote:
> > > Just got http://kodu.ut.ee/~mroos/4.6-dmar-fault2.png when playing with
> > > BIOS settings (disabling NUMA). It is the first time I see at least some
> > > info in NMI decode.
> >
> > This looks interesting. Can you please post
On Fri, Jun 24, 2016 at 06:13:14AM -0700, Nadav Amit wrote:
> According to the manual: "Hardware access to ... invalidation queue ...
> are always coherent."
>
> Remove unnecassary clflushes accordingly.
>
> Signed-off-by: Nadav Amit
Applied, thanks.
__
On Wed, Jul 13, 2016 at 05:44:24PM +0800, Wan Zongshun wrote:
>
>
> On 2016年07月12日 18:55, Joerg Roedel wrote:
> >This branch boots now on my Kaveri and Carrizo system. Can you please
> >give it a test too?
>
> Joerg, I have tested the patches, it works now.
Great, thanks a lot for your testing.
On Wed, Jul 13, 2016 at 12:40:39PM +0300, Meelis Roos wrote:
> Just got http://kodu.ut.ee/~mroos/4.6-dmar-fault2.png when playing with
> BIOS settings (disabling NUMA). It is the first time I see at least some
> info in NMI decode.
This looks interesting. Can you please post output of 'lspci -vv
On 2016年07月12日 18:55, Joerg Roedel wrote:
Hey Vincent,
On Tue, Jul 12, 2016 at 05:03:08PM +0800, Wan Zongshun wrote:
Currently, those patches can not work at my eCarrizo board.
When I merged your patches, boot failed, and no any info print to me.
I set iommu=pt, it also does not work; set iom
On Wed, Jul 13, 2016 at 12:16:46PM +0300, Meelis Roos wrote:
> ROM setup settings that might be of interest:
>
> Advanced memory protection: advanced ecc support
> No-Execute memory protection: enabled
> Intel virtualization technology: enabled
> Intel hyperthreading options: enabled
> Processor c
> > > Can you probably use the faulty config and bisect this down to a
> > > specific commit? In v4.7-rc1 some changes to the iova-allocation code
> > > got merged, but I have no idea how those could cause NMIs.
> >
> > Will try but I do not know a working base yet - this was broken in both
> > 4
> > > > Bisecting kernel configs shows that it's DMAR+IOMMU. When it is
> > > > activated, there is high probability of NMI-s in random places.
> > >
> > > Hmm, strange. But nothing could really surprise when you have an HP
> > > BIOS.
> >
> > BIOS P64 01/22/2015. There seems to be a newer 2015.
On Wed, Jul 13, 2016 at 11:31:02AM +0300, Meelis Roos wrote:
> > > Bisecting kernel configs shows that it's DMAR+IOMMU. When it is
> > > activated, there is high probability of NMI-s in random places.
> >
> > Hmm, strange. But nothing could really surprise when you have an HP
> > BIOS.
>
> BIOS
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.
Signed-off-by: Krzysztof Kozlowski
[for iommu]
Acked-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iommu/i
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.
Signed-off-by: Krzysztof Kozlowski
---
arch/x86/include/asm/dma-mapping.h | 5 ++---
arch/x86/include/asm/swiotlb.h | 4 ++--
arch/x86/include/asm/xen/page-coherent.h | 9 -
After switching DMA attributes to unsigned long it is easier to just
compare the bits.
Signed-off-by: Krzysztof Kozlowski
[for avr32]
Acked-by: Hans-Christian Noren Egtvedt
[for arc]
Acked-by: Vineet Gupta
[for arm64 and dma-iommu]
Acked-by: Robin Murphy
---
Documentation/DMA-API.txt
Split out subsystem specific changes for easier reviews. This will be
squashed with main commit.
Signed-off-by: Krzysztof Kozlowski
[for iommu]
Acked-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 12 ++--
drivers/iommu/dma-iommu.c | 6 +++---
include/linux/dma-iommu.h | 6 +++---
3
Hi,
The fifth version of this patchset was merged by Andrew Morton
few days ago. It was rebased on v4.7-rc5 so it missed some ongoing
changes.
This is just rebase on next-20160713.
For easier testing the patchset is available here:
repo: https://github.com/krzk/linux
branch: for-next/dma
> > Bisecting kernel configs shows that it's DMAR+IOMMU. When it is
> > activated, there is high probability of NMI-s in random places.
>
> Hmm, strange. But nothing could really surprise when you have an HP
> BIOS.
BIOS P64 01/22/2015. There seems to be a newer 2015.08.16 BIOS out but
the rele
On Wed, Jul 13, 2016 at 10:17:59AM +0300, Meelis Roos wrote:
> Bisecting kernel configs shows that it's DMAR+IOMMU. When it is
> activated, there is high probability of NMI-s in random places.
Hmm, strange. But nothing could really surprise when you have an HP
BIOS.
Can you probably use the faul
> > > > On HP Proliant DL360 G6, Debian unstable 4.6 kernel runs fine but
> > > > selfcompiled 4.7-rc6 and 4.7-rc7 sometimes crash with NMI from
> > > > intel_idle. Sometimes it boots fine. With intel_idle disabled, it has
> > > > booted successful so far in 2 tries, one with rc6 and one with rc
30 matches
Mail list logo
