IOMMU Archive on lore.kernel.org
 help / color / Atom feed
* [BISECTED REGRESSION 5.3-rc2] Marvell 88SE9128 SATA controller unusable with intel_iommu=on
@ 2019-08-24 16:20 Stijn Tintel
  2019-08-25  2:06 ` Lu Baolu
  0 siblings, 1 reply; 2+ messages in thread
From: Stijn Tintel @ 2019-08-24 16:20 UTC (permalink / raw)
  To: Joerg Roedel, Lu Baolu
  Cc: Kevin Tian, Ashok Raj, Xu Pengfei, iommu, Alex Williamson,
	David Woodhouse

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [BISECTED REGRESSION 5.3-rc2] Marvell 88SE9128 SATA controller unusable with intel_iommu=on
  2019-08-24 16:20 [BISECTED REGRESSION 5.3-rc2] Marvell 88SE9128 SATA controller unusable with intel_iommu=on Stijn Tintel
@ 2019-08-25  2:06 ` Lu Baolu
  0 siblings, 0 replies; 2+ messages in thread
From: Lu Baolu @ 2019-08-25  2:06 UTC (permalink / raw)
  To: Stijn Tintel, Joerg Roedel
  Cc: Kevin Tian, Ashok Raj, Alex Williamson, iommu, Xu Pengfei,
	David Woodhouse

Hi,

I am looking into this and will come up with a fix.

Best regards,
Baolu

On 8/25/19 12:20 AM, Stijn Tintel wrote:
> 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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, back to index

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-24 16:20 [BISECTED REGRESSION 5.3-rc2] Marvell 88SE9128 SATA controller unusable with intel_iommu=on Stijn Tintel
2019-08-25  2:06 ` Lu Baolu

IOMMU Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-iommu/0 linux-iommu/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-iommu linux-iommu/ https://lore.kernel.org/linux-iommu \
		iommu@lists.linux-foundation.org iommu@archiver.kernel.org
	public-inbox-index linux-iommu


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.linux-foundation.lists.iommu


AGPL code for this site: git clone https://public-inbox.org/ public-inbox