Date: Sun, 14 Nov 2010 16:27:59 -0800 From: Pyun YongHyeon <pyunyh@gmail.com> To: Alexander Motin <mav@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Pyun YongHyeon <yongari@freebsd.org> Subject: Re: svn commit: r215327 - head/sys/dev/nfe Message-ID: <20101115002759.GA1351@michelle.cdnetworks.com> In-Reply-To: <4CE07AA3.6040205@FreeBSD.org> References: <201011142337.oAENbheD097425@svn.freebsd.org> <4CE07AA3.6040205@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 15, 2010 at 02:11:15AM +0200, Alexander Motin wrote: > Pyun YongHyeon wrote: > > Author: yongari > > Date: Sun Nov 14 23:37:43 2010 > > New Revision: 215327 > > URL: http://svn.freebsd.org/changeset/base/215327 > > > > Log: > > 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. > > MCP5x seem to be infinite source of surprises. Some reports I remember: Yeah, they even do not release any errata. > - snd_hda not working with MSI enabled - AFAIR not just loosing > interrupts but completely stops responding; > - using regular HPET interrupts breaks HDA sound after some time > (interrupts are not shared), while legacy_route mode operates properly; > - at least on one system I've seen non-functioning SATA interrupts. > It would be nice to find what's going on there. I've got tired to add > workarounds for it. :( > Yeah, I agree but I'm sure not all MCP55 was broken because one user who tested MCP55 with MSI-X reported success. This is reason why I didn't add it to system-wide blacklist table. If you remember exact PCI bridge chipset I think you can compare it with the pciconf output in PR/152150 and if it's the same we can move it to PCI quirk table.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101115002759.GA1351>