lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 6 Mar 2013 10:48:25 +0800
From:	Andrew Cooks <acooks@...il.com>
To:	Gaudenz Steinlin <gaudenz@...iologie.ch>
Cc:	jyli@...vell.com,
	"open list:INTEL IOMMU (VT-d)" <iommu@...ts.linux-foundation.org>,
	open list <linux-kernel@...r.kernel.org>,
	Shun Fu <fushun@...vell.com>,
	Alex Williamson <alex.williamson@...hat.com>
Subject: Re: Marvell 88NV9143 in mini-PCIe not working with intel_iommu=on

On Tue, Mar 5, 2013 at 11:03 PM, Gaudenz Steinlin <gaudenz@...iologie.ch> wrote:
>
> [ Sending this to the MVUMI driver authors and the IOMMU list as I can't
> tell which part is at fault. ]
>
> [ ... ]
> [    4.342079] dmar: DRHD: handling fault status reg 2
> [    4.342132] dmar: DMAR:[DMA Read] Request device [02:00.0] fault addr fffff000
> [    4.342132] DMAR:[fault reason 02] Present bit in context entry is clear
> [ ... ]
> [   34.344078] mvumi 0000:02:00.1: no handshake response at state 0x2.
> [   34.344115] mvumi 0000:02:00.1: isr : global=0x0,status=0x0.
> [   34.344146] mvumi 0000:02:00.1: handshake failed at state 0x2.
> [   34.344266] mvumi: probe of 0000:02:00.1 failed with error -22
>

Looks like another Marvell DMA source tag issue.

> And the full lspic output for this device:
>
> gaudenz@...eor:~$ sudo lspci -vv -nnq -s 02:
> 02:00.0 Mass storage controller [01ff]: Marvell Technology Group Ltd. Device [1b4b:91f3]
>         Subsystem: Marvell Technology Group Ltd. Device [1b4b:9143]
> ...
>         Capabilities: [140 v1] Virtual Channel
>                 Caps:   LPEVC=0 RefClk=100ns PATEntryBits=1
>                 Arb:    Fixed- WRR32- WRR64- WRR128-
>                 Ctrl:   ArbSelect=Fixed
>                 Status: InProgress-
>                 VC0:    Caps:   PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
>                         Arb:    Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
>                         Ctrl:   Enable+ ID=0 ArbSelect=Fixed TC/VC=01
>                         Status: NegoPending- InProgress-
>
> 02:00.1 Mass storage controller [0180]: Marvell Technology Group Ltd. Device [1b4b:9143] (rev 10)
>         Subsystem: Marvell Technology Group Ltd. Device [1b4b:9143]
> ...
>         Kernel driver in use: mvumi
>
> 02:00.2 Non-Volatile memory controller [0108]: Marvell Technology Group Ltd. Device [1b4b:91e3] (prog-if 01)
>         Subsystem: Marvell Technology Group Ltd. Device [1b4b:9143]
>...

In this case it seems like a multifunction device with 02:00.1 being
the only function that the mvumi driver cares about.  So my guess is
that 02:00.1 is issuing DMA with the incorrect tag of 02:00.0.

Perhaps Alex Williamson can tell us about iommu device groups, whether
it would be possible to group the functions together automatically and
whether that would solve the problem. It should also be possible to
adapt the quirk patch I posted recently to handle this, but I'm still
waiting to hear if that patch has a future.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ