On Thu, 14 Jul 2016 00:04:44 -0500 David <david...@gmail.com> wrote: > Building my own Kernel is way beyond my current comfort level with > Linux. I am very much a newbie here. > > Is this fix a relatively simple kernel patch? Or maybe something that > can be added to a config file somewhere?
Ok, you said you were running F24, here are the kernel rpms with the fix already applied: http://people.redhat.com/~alwillia/adaptec-3805/ If this works for you, I'll post the patch upstream. Thanks, Alex > On Wed, Jul 13, 2016 at 11:26 PM, Alex Williamson > <alex.william...@redhat.com> wrote: > > On Wed, 13 Jul 2016 19:28:31 -0500 > > David <david...@gmail.com> wrote: > > > >> Ok, Rebooted when i got home and ran the Dmesg command again to save > >> you a full copy. This time its full of errors.... > >> I have no idea what changed. > >> > >> But the errors are for a device address that has no hardware. > >> > >> I have attached the error log. > >> > >> # lspci -v -s 03:01.0 > >> **Nothing** > > > > Ah yes, this begins to spark some memories: > > > > commit d3d2ab43ddae5f958461ac0a9a2b484a68194df5 > > Author: Alex Williamson <alex.william...@redhat.com> > > Date: Tue Jan 13 11:26:50 2015 -0700 > > > > PCI: Add DMA alias quirk for Adaptec 3405 > > > > The Adaptec 3405 is actually an Intel 80333 I/O processor where the > > exposed > > device at 0e.0 is actually the address translation unit of the I/O > > processor and a hidden, private device at 01.0 masters the DMA for the > > device. Create a fixed alias between the exposed and hidden devfn so we > > can enable the IOMMU. > > > > Scenarios like this are potentially likely for any device incorporating > > this I/O processor, so this little bit of abstraction with the fixed > > alias > > table should make future additions trivial. > > > > Without this fix, booting a system with the Intel IOMMU enabled and an > > Adaptec 3405 at 02:0e.0 results in a flood of errors like this: > > > > dmar: DRHD: handling fault status reg 3 > > dmar: DMAR:[DMA Write] Request device [02:01.0] fault addr ffbff000 > > DMAR:[fault reason 02] Present bit in context entry is clear > > > > [bhelgaas: changelog, comment] > > Signed-off-by: Alex Williamson <alex.william...@redhat.com> > > Signed-off-by: Bjorn Helgaas <bhelg...@google.com> > > CC: Adaptec OEM Raid Solutions <aacr...@adaptec.com> > > > > That went into kernel v4.0, but Adaptec never commented and we don't > > know how widespread the problem is, so the fix only covers a specific > > subsystem ID. If you're able to patch and build your own kernel, try > > this: > > > > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c > > index ee72ebe..c5bd47d 100644 > > --- a/drivers/pci/quirks.c > > +++ b/drivers/pci/quirks.c > > @@ -3747,6 +3747,9 @@ static const struct pci_device_id > > fixed_dma_alias_tbl[] = { > > { PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x0285, > > PCI_VENDOR_ID_ADAPTEC2, 0x02bb), /* Adaptec 3405 */ > > .driver_data = PCI_DEVFN(1, 0) }, > > + { PCI_DEVICE_SUB(PCI_VENDOR_ID_ADAPTEC2, 0x0285, > > + PCI_VENDOR_ID_ADAPTEC2, 0x02bc), /* Adaptec 3805 */ > > + .driver_data = PCI_DEVFN(1, 0) }, > > { 0 } > > }; > > > > I'm grabbing the subsystem device ID from > > http://pci-ids.ucw.cz/read/PC/9005/0285/900502bc Please verify with > > 'lspci -nnvs 3:0e.0' that your subsystem is 9005:02bc. Thanks, > > > > Alex > > > _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
