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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 1 Jan 2015, at 19:28, Steven Hartland <killing@multiplay.co.uk> =
wrote:
>=20
> 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.
>>>=20
>>> So given all the evidence so far ahci.0.msi=3D1 may well be the fix.
>>>=20
>> Is there any benefit to also trying with mdi > 1 < 8?
> Nope as the ahci(4) details there's only 3 settings:
> 0 =3D MSI disabled
> 1 =3D Single MSI vector used, if supported
> 2 =3D Multiple MSI vectors used, if supported (default)
>=20
> 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=E2=80=99ve set it in boot.loader:
$ cat /boot/loader.conf=20
zfs_load=3D=E2=80=9CYES"
ahci.0.msi=3D1
However, it=E2=80=99s 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=E2=80=99s confusing - I was expecting it to only route a single =
vector.
That sysctl isn=E2=80=99t 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=3D17 function=3D0 handle=3D\_SB_.PCI0.SATA
dev.ahci.0.%pnpinfo: vendor=3D0x1002 device=3D0x4391 =
subvendor=3D0x103c subdevice=3D0x1609 class=3D0x010601
dev.ahci.0.%parent: pci0
Is it only in -current perchance?
Thanks,
Joe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3235C789-E677-4FA0-91CA-4C8F5DF17F99>