[Bug 42679] New: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU is on
Paweł Żak
pawel.zaq at gmail.com
Mon Jan 30 22:13:02 UTC 2012
On Mon, 30 Jan 2012 22:41:32 +0100, Don Dutile <ddutile at redhat.com> wrote:
> On 01/30/2012 03:59 PM, Andrew Morton wrote:
>>
>> (switched to email. Please respond via emailed reply-to-all, not via
>> the
>> bugzilla web interface).
>>
>> On Sat, 28 Jan 2012 17:55:38 GMT
>> bugzilla-daemon at bugzilla.kernel.org wrote:
>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=42679
>>
>> I don't know if this is a SATA issue or intel-iommu. Could you guys
>> please take a look?
>>
>>> Summary: DMA Read on Marvell 88SE9128 fails when Intel's
>>> IOMMU
>>> is on
>>> Product: Memory Management
>>> Version: 2.5
>>> Platform: All
>>> OS/Version: Linux
>>> Tree: Mainline
>>> Status: NEW
>>> Severity: normal
>>> Priority: P1
>>> Component: Other
>>> AssignedTo: akpm at linux-foundation.org
>>> ReportedBy: pawel.zaq at gmail.com
>>> Regression: No
>>>
>>>
>>> Created an attachment (id=72217)
>>> --> (https://bugzilla.kernel.org/attachment.cgi?id=72217)
>>> Output of `dmesg' command
>>>
>>> I have a MSI Z68A-GD80 B3 motherboard and when I try to enable Intel's
>>> IOMMU
>>> (kernel booted with intel_iommu=on), integrated Marvell 88SE9128 SATA
>>> controller doesn't work.
>>>
>>> To reproduce:
>>> 1. Compile and prepare kernel with Intel IOMMU support enabled
>>> (CONFIG_INTEL_IOMMU=y).
>>> 2. Reboot the computer.
>>> 3. Enter BIOS and enable VT-d.
>>> 4. Boot the kernel with intel_iommu=on parameter.
>>>
>>> Right after boot, kernel reports the following errors (SATA controller
>>> is at
>>> 0b:00.0):
>>>
>>> [ 2.639774] DRHD: handling fault status reg 3
>>> [ 2.639782] DMAR:[DMA Read] Request device [0b:00.1] fault addr
>>> fff00000
>>> [ 2.639783] DMAR:[fault reason 02] Present bit in context entry is
>>> clear
>>>
>>> After a while these entries appear:
>>>
>>> [ 7.625837] ata14.00: qc timeout (cmd 0xa1)
>>> [ 7.628341] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4)
>>> [ 7.935483] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>>> [ 17.908407] ata14.00: qc timeout (cmd 0xa1)
>>> [ 17.910935] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4)
>>> [ 17.912276] ata14: limiting SATA link speed to 1.5 Gbps
>>> [ 18.219077] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>>> [ 48.134607] ata14.00: qc timeout (cmd 0xa1)
>>> [ 48.137508] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4)
>>> [ 48.444646] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
>>>
>>> When there is a disk connected to the controller it does not work.
>>> When there
>>> are none, computer starts normally, apart from the huge lag caused by,
>>> presumably, probing the device.
>>>
>>> Since this is the secondary controller on these motherboards, to
>>> eliminate
>>> those symptoms you can just plug disk in one of available ports of the
>>> built-in
>>> Intel SATA controller and disable Marvell's one using BIOS. The other
>>> work-around, if you need to use eSATA capabilities of the latter, is
>>> to disable
>>> VT-d techonology also using BIOS.
>>
>>
>> _______________________________________________
>> iommu mailing list
>> iommu at lists.linux-foundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/iommu
>
> Well, the lspci dump in the bugzilla report doesn't show a device
> w/BDF=0b:00.1;
> so, if the SATA device (which is 0b:00.0) is spitting out 0b:00.1 as the
> source
> of any of its DMA packets, the IOMMU will fault on it, since 0b:00.1
> didn't
> request DMA mappings (0b:00.0 did).
> I semi-recall someone else reporting this 'feature' on this list.
> Wonder if pci-quirk has to filter this case (0b:00.0 on this system means
> map for 0b:00.0 & 0b:00.1 -- ick!)
>
> do another lspci -vvv to ensure that 0b:00.1 wasn't excluded in the list.
> if it doesn't exist, then the problem is the SATA device using an
> unknown/unrecognized
> BDF of 0b:00.1
Yep, that's correct. I enabled all integrated peripherals on my
motherboard and there were still no entries with BDF 0b:00.1 in lspci -vvv
output. Should I take this problem to MSI then?
Paweł
More information about the iommu
mailing list