Date: Sat, 24 Jan 2015 20:09:47 +0000 From: Dr Josef Karthauser <joe@tao.org.uk> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-stable@freebsd.org Subject: Re: Creating a bootable ZFS disk? Message-ID: <3235C789-E677-4FA0-91CA-4C8F5DF17F99@tao.org.uk> In-Reply-To: <54A59FE8.2070008@multiplay.co.uk> References: <54a048f2.45c1c20a.6ffd.ffffe6d7SMTPIN_ADDED_BROKEN@mx.google.com> <54A062FE.6020500@multiplay.co.uk> <54A067D0.4050606@multiplay.co.uk> <349F0A87-5F85-4367-9A5C-E77DBFA16588@karthauser.co.uk> <7E1DA790-822F-4253-A3F6-1E5F5EFFEE04@karthauser.co.uk> <54A1129F.3040004@multiplay.co.uk> <C0A39010-8EBD-46C6-8AA5-B7970DF5280B@tao.org.uk> <54A18986.4000002@multiplay.co.uk> <5AFFE5CE-ABC7-4D9C-B8E7-0AC9C3327D6B@tao.org.uk> <54A2D3FA.6000404@multiplay.co.uk> <18C4C5D1-04D8-46B3-9E6F-FDAEB49BED1A@tao.org.uk> <54A59FE8.2070008@multiplay.co.uk>
index | next in thread | previous in thread | raw e-mail
> On 1 Jan 2015, at 19:28, Steven Hartland <killing@multiplay.co.uk> wrote:
>
> On 01/01/2015 17:18, Dr Josef Karthauser wrote:
>> On 30 Dec 2014, at 16:34, Steven Hartland <killing@multiplay.co.uk> wrote:
>>> This is strengthened by the fact that ATI's previous generation HW (SB600) had MSI disabled by r245875 due to a very similar issue.
>>>
>>> So given all the evidence so far ahci.0.msi=1 may well be the fix.
>>>
>> Is there any benefit to also trying with mdi > 1 < 8?
> Nope as the ahci(4) details there's only 3 settings:
> 0 = MSI disabled
> 1 = Single MSI vector used, if supported
> 2 = Multiple MSI vectors used, if supported (default)
>
> If setting it to 1 does fix it, I've got a patch which provides a quirk we can use to make that the default for this HW.
Finally got the machine into a state I can test it - sorry for the delay.
I’ve set it in boot.loader:
$ cat /boot/loader.conf
zfs_load=“YES"
ahci.0.msi=1
However, it’s still allocating all 8 vectors:
$ dmesg | grep MSI
[cut]
ahci0: attempting to allocate 8 MSI vectors (8 supported)
msi: routing MSI IRQ 263 to local APIC 0 vector 64
msi: routing MSI IRQ 264 to local APIC 0 vector 65
msi: routing MSI IRQ 265 to local APIC 0 vector 66
msi: routing MSI IRQ 266 to local APIC 0 vector 67
msi: routing MSI IRQ 267 to local APIC 0 vector 68
msi: routing MSI IRQ 268 to local APIC 0 vector 69
msi: routing MSI IRQ 269 to local APIC 0 vector 70
msi: routing MSI IRQ 270 to local APIC 0 vector 71
ahci0: using IRQs 263-270 for MSI
[cut]
This is with:
$ uname -a
FreeBSD my.machine.and.domain 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
So, that’s confusing - I was expecting it to only route a single vector.
That sysctl isn’t exposed as a read variable:
$ sysctl -a | grep ahci.0
dev.ahci.0.%desc: AMD SB7x0/SB8x0/SB9x0 AHCI SATA controller
dev.ahci.0.%driver: ahci
dev.ahci.0.%location: slot=17 function=0 handle=\_SB_.PCI0.SATA
dev.ahci.0.%pnpinfo: vendor=0x1002 device=0x4391 subvendor=0x103c subdevice=0x1609 class=0x010601
dev.ahci.0.%parent: pci0
Is it only in -current perchance?
Thanks,
Joe
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3235C789-E677-4FA0-91CA-4C8F5DF17F99>
