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...@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....@intel.com> Cc: Jacob Pan <jacob.jun....@linux.intel.com> Cc: Kevin Tian <kevin.t...@intel.com> Fixes: fa954e6831789 ("iommu/vt-d: Delegate the dma domain to upper layer") Signed-off-by: Lu Baolu <baolu...@linux.intel.com> Reported-and-tested-by: Xu Pengfei <pengfei...@intel.com> Signed-off-by: Joerg Roedel <jroe...@suse.de> :040000 040000 010e7057b8401481e7258948786a2658f9f14037 18aeac50a60d8b8424fcdccd0b3118f565ce3909 M drivers Stijn
_______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
