[vfio-users] intel_iommu=on and aacraid / Adaptec 3805
David
david283 at gmail.com
Sun Jul 17 10:32:29 UTC 2016
OK, installed all these rpms and rebooted. IOMMU is still on, but
sadly the Raid volume still isn't showing up. Rebooted a second time
to be sure. Attaching new error log.
$ uname -r
4.6.4-302.aw0.fc24.x86_64
# lsblk -f
NAME FSTYPE LABEL
UUID MOUNTPOINT
sda
├─sda1 vfat efi
9E87-0ECF /boot/efi
├─sda2 ext4 boot
4f8d2664-8fc0-4779-ac18-6f0c06152d27 /boot
└─sda3 crypto_LUKS
ccee7bd2-4dce-4966-addb-bba6194ade93
└─luks-ccee7bd2-4dce-4966-addb-bba6194ade93 LVM2_member
MePSH6-Fo6u-3mNp-ou31-uU4r-rCVz-5sPM79
├─linuslvm1-root crypto_LUKS
5101eab0-8b88-414f-8ec8-ec8dbe3e6791
│ └─luks-5101eab0-8b88-414f-8ec8-ec8dbe3e6791 ext4 root
3f788b0c-9721-4359-9f09-5dbc6a37d8e9 /
└─linuslvm1-swap swap swap
5e897a06-decb-4001-b60d-baabaa056b70 [SWAP]
sdb
# lspci -v -s 03:0e.0
03:0e.0 RAID bus controller: Adaptec AAC-RAID
Subsystem: Adaptec 3805
Flags: bus master, stepping, 66MHz, medium devsel, latency 32, IRQ 60
Memory at fa600000 (64-bit, non-prefetchable) [size=2M]
Expansion ROM at fa800000 [disabled] [size=256K]
Capabilities: [c0] Power Management version 2
Capabilities: [d0] MSI: Enable- Count=1/2 Maskable- 64bit+
Capabilities: [e0] PCI-X non-bridge device
Kernel driver in use: aacraid
Kernel modules: aacraid
On Thu, Jul 14, 2016 at 1:51 PM, Alex Williamson
<alex.williamson at redhat.com> wrote:
> 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
>>
>>
>>
>
--
David
david283 at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: errorlog3
Type: application/octet-stream
Size: 279376 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/vfio-users/attachments/20160717/c0459627/attachment.obj>
More information about the vfio-users
mailing list