[BISECTED REGRESSION 5.3-rc2] Marvell 88SE9128 SATA controller unusable with intel_iommu=on

[Stijn Tintel <stijn@linux-ipv6.be>]

Hi,

There is a bug in kernel 5.3-rc2 and later that breaks my Marvell
88SE9128 SATA controller. The problem does not occur when I boot with
intel_iommu=off. This seems to be a regression of
https://bugzilla.kernel.org/show_bug.cgi?id=42679. A quirk was added to
fix this, in cc346a4714a59d08c118e8f33fd86692d3563133. This quirk is
still in place, but it appears that it is no longer working.

aug 23 18:04:17 taz kernel: DMAR: DRHD: handling fault status reg 2
aug 23 18:04:17 taz kernel: ata7: SATA link up 6.0 Gbps (SStatus 133
SControl 300)
aug 23 18:04:17 taz kernel: ata9: SATA link down (SStatus 0 SControl 300)
aug 23 18:04:17 taz kernel: ata8: SATA link down (SStatus 0 SControl 300)
aug 23 18:04:17 taz kernel: ata10: SATA link down (SStatus 0 SControl 300)
aug 23 18:04:17 taz kernel: ata11: SATA link down (SStatus 0 SControl 300)
aug 23 18:04:17 taz kernel: ata5.00: 1953525168 sectors, multi 16: LBA48
NCQ (depth 32), AA
aug 23 18:04:17 taz kernel: DMAR: [DMA Read] Request device [09:00.1]
fault addr fff00000 [fault reason 02] Present bit in context entry is clear
...
aug 23 18:04:17 taz kernel: sd 5:0:0:0: [sde] Attached SCSI disk
aug 23 18:04:17 taz kernel: ata14.00: qc timeout (cmd 0xa1)
aug 23 18:04:17 taz kernel: ata7.00: qc timeout (cmd 0xec)
aug 23 18:04:17 taz kernel: ata14.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
aug 23 18:04:17 taz kernel: ata7.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
aug 23 18:04:17 taz kernel: ata14: SATA link up 1.5 Gbps (SStatus 113
SControl 300)
aug 23 18:04:17 taz kernel: ata7: link is slow to respond, please be
patient (ready=0)
aug 23 18:04:17 taz kernel: ata7: COMRESET failed (errno=-16)
aug 23 18:04:17 taz kernel: ata14.00: qc timeout (cmd 0xa1)
aug 23 18:04:17 taz kernel: ata14.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
aug 23 18:04:17 taz kernel: ata14: SATA link up 1.5 Gbps (SStatus 113
SControl 300)
aug 23 18:04:17 taz kernel: ata7: link is slow to respond, please be
patient (ready=0)
aug 23 18:04:17 taz kernel: ata7: COMRESET failed (errno=-16)
aug 23 18:04:17 taz kernel: ata7: link is slow to respond, please be
patient (ready=0)
aug 23 18:04:17 taz kernel: ata14.00: qc timeout (cmd 0xa1)
aug 23 18:04:17 taz kernel: ata14.00: failed to IDENTIFY (I/O error,
err_mask=0x4)
aug 23 18:04:17 taz kernel: ata14: SATA link up 1.5 Gbps (SStatus 113
SControl 300)
aug 23 18:04:17 taz kernel: ata7: COMRESET failed (errno=-16)
aug 23 18:04:17 taz kernel: ata7: limiting SATA link speed to 3.0 Gbps
aug 23 18:04:17 taz kernel: ata7: COMRESET failed (errno=-16)
aug 23 18:04:17 taz kernel: ata7: reset failed, giving up


This is the outcome of git bisect:

557529494d79f3f1fadd486dd18d2de0b19be4da is the first bad commit
commit 557529494d79f3f1fadd486dd18d2de0b19be4da
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Tue Jul 9 13:22:45 2019 +0800

    iommu/vt-d: Avoid duplicated pci dma alias consideration

    As we have abandoned the home-made lazy domain allocation
    and delegated the DMA domain life cycle up to the default
    domain mechanism defined in the generic iommu layer, we
    needn't consider pci alias anymore when mapping/unmapping
    the context entries. Without this fix, we see kernel NULL
    pointer dereference during pci device hot-plug test.

    Cc: Ashok Raj <ashok.raj@intel.com>
    Cc: Jacob Pan <jacob.jun.pan@linux.intel.com>
    Cc: Kevin Tian <kevin.tian@intel.com>
    Fixes: fa954e6831789 ("iommu/vt-d: Delegate the dma domain to upper
layer")
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Reported-and-tested-by: Xu Pengfei <pengfei.xu@intel.com>
    Signed-off-by: Joerg Roedel <jroedel@suse.de>

:040000 040000 010e7057b8401481e7258948786a2658f9f14037
18aeac50a60d8b8424fcdccd0b3118f565ce3909 M      drivers

Stijn

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu