summaryrefslogtreecommitdiffstats
path: root/sys/dev/xl
diff options
context:
space:
mode:
authoryongari <yongari@FreeBSD.org>2010-11-14 23:37:43 +0000
committeryongari <yongari@FreeBSD.org>2010-11-14 23:37:43 +0000
commit5a7162f62d8d21d7ec6fa137495afbab65b3688a (patch)
treeef6bd73687225e86627993311b145462602f678a /sys/dev/xl
parentbe16647d2886c423de954843da55b62db5466df2 (diff)
downloadFreeBSD-src-5a7162f62d8d21d7ec6fa137495afbab65b3688a.zip
FreeBSD-src-5a7162f62d8d21d7ec6fa137495afbab65b3688a.tar.gz
P5N32-SLI PREMIUM from ASUSTeK is known to have MSI/MSI-X issue
such that nfe(4) does not work with MSI-X. When MSI-X support was introduced, I remember MCP55 controller worked without problems so the issue could be either PCI bridge or BIOS issue. But I also noticed snd_hda(4) disabled MSI on all MCP55 chipset so I'm still not sure this is generic issue of MCP55 chipset. If this was PCI bridge issue we would have added it to a system wide black-list table but it's not clear to me at this moment whether it was caused by either broken BIOS or silicon bug of MCP55 chipset. To workaround the issue, maintain a MSI/MSI-X black-list table in driver and lookup base board manufacturer and product name from the table before attempting to use MSI-X. If driver find an matching entry, nfe(4) will not use MSI/MSI-X and fall back on traditional INTx mode. This approach should be the last resort since it relies on smbios and if another instance of MSI/MSI-X breakage is reported with different maker/product, we may have to get the PCI bridge black-listed instead of adding an new entry. PR: kern/152150
Diffstat (limited to 'sys/dev/xl')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud