[vfio-users] intel_iommu=on and aacraid / Adaptec 3805
Alex Williamson
alex.williamson at redhat.com
Thu Jul 14 18:51:49 UTC 2016
On Thu, 14 Jul 2016 00:04:44 -0500
David <david283 at 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.williamson at redhat.com> wrote:
> > On Wed, 13 Jul 2016 19:28:31 -0500
> > David <david283 at 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.williamson at 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.williamson at redhat.com>
> > Signed-off-by: Bjorn Helgaas <bhelgaas at google.com>
> > CC: Adaptec OEM Raid Solutions <aacraid at 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
>
>
>
More information about the vfio-users
mailing list