]> CyberLeo.Net >> Repos - FreeBSD/releng/9.2.git/commit
MFC: r254004
authormarius <marius@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Fri, 9 Aug 2013 18:57:18 +0000 (18:57 +0000)
committermarius <marius@ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f>
Fri, 9 Aug 2013 18:57:18 +0000 (18:57 +0000)
commit90bea385446a712c3d1c7126eedf1742d310409c
treec4990e7a79cd94ba794e2af91c3f93f3b6da8e3f
parent5a09b855fbc0ca03baf25671268474a9cb8e15a1
MFC: r254004

As it turns out, MSIs are broken with 2820SA so introduce an AAC_FLAGS_NOMSI
quirk and apply it to these controllers [1]. The same problem was reported
for 2230S, in which case it wasn't actually clear whether the culprit is the
controller or the mainboard, though. In order to be on the safe side, flag
MSIs as being broken with the latter type of controller as well. Given that
these are the only reports of MSI-related breakage with aac(4) so far and
OSes like OpenSolaris unconditionally employ MSIs for all adapters of this
family, however, it doesn't seem warranted to generally disable the use of
MSIs in aac(4).
While at it, simplify the MSI allocation logic a bit; there's no need to
check for the presence of the MSI capability on our own as pci_alloc_msi(9)
will just fail when these kind of interrupts are not available.
Reported and tested by: David Boyd [1]

Approved by: re (kib)

git-svn-id: svn://svn.freebsd.org/base/releng/9.2@254154 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
sys/dev/aac/aac_pci.c
sys/dev/aac/aacvar.h