Comment 69 for bug 1810239

(In reply to Joshua Scoggins from comment #51)
> Created attachment 134871 [details]
> More Verbose DMESG output for tycho (z9pe-d8 WS, x79 + C600)
>
> Sorry about that, I thought I saw the DMAR error in those logs.....
> I enabled heavy debug mode this time and confirmed I saw the DMAR errors and
> have attached that log.

Your log doesn't seem to match the issues others are having. There's only a single DMAR fault:

[ 1.887994] dmar: DRHD: handling fault status reg 2
[ 1.888349] dmar: DMAR:[DMA Read] Request device [0b:00.0] fault addr 0
DMAR:[fault reason 06] PTE Read access is not set

This is a read access to physical address 0x0 from function 0. It seems valid for the IOMMU to block this, the driver can possibly have mapped a buffer at 0x0. Later the log shows problems probing these channels:

[ 7.193298] ata8.00: qc timeout (cmd 0xec)
[ 7.194320] ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 7.197283] ata14.00: qc timeout (cmd 0xa1)
[ 7.198266] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 7.237279] ata7: link is slow to respond, please be patient (ready=0)
[ 7.238300] ata9: link is slow to respond, please be patient (ready=0)
[ 7.513247] ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 7.517218] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 11.884142] ata9: COMRESET failed (errno=-16)
[ 11.885130] ata7: COMRESET failed (errno=-16)
[ 17.242784] ata9: link is slow to respond, please be patient (ready=0)
[ 17.243720] ata7: link is slow to respond, please be patient (ready=0)
[ 17.510746] ata8.00: qc timeout (cmd 0xec)
[ 17.511561] ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 17.512361] ata8: limiting SATA link speed to 1.5 Gbps
[ 17.514750] ata14.00: qc timeout (cmd 0xa1)
[ 17.515498] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 17.516231] ata14: limiting SATA link speed to 1.5 Gbps
[ 17.830691] ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 310)
[ 17.834674] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 21.889672] ata7: COMRESET failed (errno=-16)
[ 21.890480] ata9: COMRESET failed (errno=-16)
[ 27.248351] ata9: link is slow to respond, please be patient (ready=0)
[ 27.249142] ata7: link is slow to respond, please be patient (ready=0)
[ 47.823276] ata8.00: qc timeout (cmd 0xec)
[ 47.823988] ata8.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 47.827246] ata14.00: qc timeout (cmd 0xa1)
[ 47.827960] ata14.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 48.143219] ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 310)
[ 48.147218] ata14: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 56.921034] ata7: COMRESET failed (errno=-16)
[ 56.921773] ata7: limiting SATA link speed to 1.5 Gbps
[ 56.922548] ata9: COMRESET failed (errno=-16)
[ 56.923265] ata9: limiting SATA link speed to 1.5 Gbps
[ 61.943795] ata9: COMRESET failed (errno=-16)
[ 61.944518] ata9: reset failed, giving up
[ 61.945297] ata7: COMRESET failed (errno=-16)
[ 61.946022] ata7: reset failed, giving up

But, there are no further DMAR faults. Can you confirm whether adding the 0x9230 ID for your device changes anything? If the device is making a stray access to address 0x0, it may simply be incompatible with an IOMMU, in which case it should probably be assigned to a passthrough domain using the iommu=pt option.