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

2019-08-24 Thread Stijn Tintel
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 fff0 [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 
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 
    Cc: Jacob Pan 
    Cc: Kevin Tian 
    Fixes: fa954e6831789 ("iommu/vt-d: Delegate the dma domain to upper
layer")
    Signed-off-by: Lu Baolu 
    Reported-and-tested-by: Xu Pengfei 
    Signed-off-by: Joerg Roedel 

:04 04 010e7057b8401481e7258948786a2658f9f14037
18aeac50a60d8b8424fcdccd0b3118f565ce3909 M  drivers

Stijn

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

Re: [RFC PATCH] Fix Intel IOMMU support for Marvell 88SE91xx SATA controllers.

2013-02-22 Thread Stijn Tintel
On 19-12-12 11:58, Andrew Cooks wrote:
 This is my second attempt to make Marvell 88SE91xx SATA controllers work when 
 IOMMU is enabled.[1][2] 
 As suggested, it no longer tries to add support for phantom functions.
 
 What's missing:
 * No AMD support. I need some help with this.
 * Table of affected chip IDs is incomplete. I think 0x9123, 0x9125, 0x9128 
 are also affected.
This one is also affected: 08:00.0 0106: 1b4b:9130 (rev 11), this is in
dmesg:

[1.914086] dmar: DMAR:[DMA Read] Request device [08:00.1] fault addr
fff0
 
 Patch is against 3.7.1
 
 Review and feedback would be appreciated.
I changed your patch to check for my chip ID, and it solves my problem:
no more hang during boot, and the HDD connected to this controller is
now detected with IOMMU enabled.

Also see 1 minor comment inline.
 
 1. https://bugzilla.redhat.com/show_bug.cgi?id=757166
 2. https://bugzilla.kernel.org/show_bug.cgi?id=42679
 
 Signed-off-by: Andrew Cooks acooks-re5jqeeqqe8avxtiumw...@public.gmane.org
 ---
  drivers/iommu/intel-iommu.c |   36 ++--
  drivers/pci/quirks.c|   34 ++
  include/linux/pci.h |1 +
  3 files changed, 66 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
 index 0badfa4..17e64c0 100644
 --- a/drivers/iommu/intel-iommu.c
 +++ b/drivers/iommu/intel-iommu.c
 @@ -1672,6 +1674,31 @@ static int domain_context_mapping_one(struct 
 dmar_domain *domain, int segment,
   return 0;
  }
  
 +/* For buggy devices like Marvell 88SE91xx chips that use unclaimed
 + * functions.
 + */
 +static int map_quirky_dma_fn(struct dmar_domain *domain,
 + struct pci_dev *pdev,
 + int translation)
 +{
 + u8 fn;
 + int err = 0;
 +
 + for (fn = 1; fn  8; fn++) {
 + if (pci_func_is_dma_source(pdev, fn)) {
 + err = domain_context_mapping_one(domain,
 + pci_domain_nr(pdev-bus),
 + pdev-bus-number,
 + PCI_DEVFN(PCI_SLOT(pdev-devfn), fn),
 + translation);
 + if (err)
 + return err;
 + dev_dbg(pdev-dev, func: %d mapped dma quirk, fn);
 + }
 + }
 + return 0;
 +}
 +
  static int
  domain_context_mapping(struct dmar_domain *domain, struct pci_dev *pdev,
   int translation)
 @@ -1685,6 +1712,11 @@ domain_context_mapping(struct dmar_domain *domain, 
 struct pci_dev *pdev,
   if (ret)
   return ret;
  
 + /* quirk for undeclared pci functions */
 + ret = map_quirky_dma_fn(domain, pdev, translation);
 + if (ret)
 + return ret;
 +
   /* dependent device mapping */
   tmp = pci_find_upstream_pcie_bridge(pdev);
   if (!tmp)
 diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
 index 7a451ff..8d02bac 100644
 --- a/drivers/pci/quirks.c
 +++ b/drivers/pci/quirks.c
 @@ -3227,6 +3227,40 @@ static const struct pci_dev_dma_source {
   { 0 }
  };
  
 +static const struct pci_dev_dma_source_funcs {
 + u16 vendor;
 + u16 device;
 + u8 func_map;/* bit map. lsb is fn 0. */
 +} pci_dev_dma_source_funcs[] = {
 +  {0x1b4b, 0x9172, (10)|(11)},
May I suggest to apply the attached patch first, and check for
PCI_VENDOR_ID_MARVELL_2 instead?
 +  { 0 }, 
 +};
 +
 +static u8 pci_get_dma_source_map(struct pci_dev *dev)
 +{
 + const struct pci_dev_dma_source_funcs *i;
 +
 + for (i = pci_dev_dma_source_funcs; i-func_map; i++) {
 + if ((i-vendor == dev-vendor ||
 +  i-vendor == (u16)PCI_ANY_ID) 
 + (i-device == dev-device ||
 +  i-device == (u16)PCI_ANY_ID)) {
 + return i-func_map; 
 + }
 + }
 + return 0;
 +}
 +
 +int pci_func_is_dma_source(struct pci_dev *dev, int fn)
 +{
 + u8 fn_map = pci_get_dma_source_map(dev);
 +
 + if (fn_map  (1  fn))
 + return 1;
 +
 + return 0;
 +}
 +
  /*
   * IOMMUs with isolation capabilities need to be programmed with the
   * correct source ID of a device.  In most cases, the source ID matches
 diff --git a/include/linux/pci.h b/include/linux/pci.h
 index ee21795..8f0fa7f 100644
 --- a/include/linux/pci.h
 +++ b/include/linux/pci.h
 @@ -1546,6 +1546,7 @@ enum pci_fixup_pass {
  #ifdef CONFIG_PCI_QUIRKS
  void pci_fixup_device(enum pci_fixup_pass pass, struct pci_dev *dev);
  struct pci_dev *pci_get_dma_source(struct pci_dev *dev);
 +int pci_func_is_dma_source(struct pci_dev *dev, int fn);
  int pci_dev_specific_acs_enabled(struct pci_dev *dev, u16 acs_flags);
  #else
  static inline void pci_fixup_device(enum pci_fixup_pass pass,
 

commit 05183aa996b2971884a60041e995b470b8224574
Author: Stijn Tintel st...@linux-ipv6.be
Date:   Sun Feb 10 01:01