Re: [Bug 42679] New: DMA Read on Marvell 88SE9128 fails when Intel's IOMMU is on

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 30 Jan 2012 22:41:32 +0100, Don Dutile <ddutile@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxx
         ReportedBy: pawel.zaq@xxxxxxxxx
         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@xxxxxxxxxxxxxxxxxxxxxxxxxx
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ł
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux