pyunyh at gmail.com
Fri Aug 11 00:24:28 UTC 2006
On Fri, Aug 11, 2006 at 05:09:19AM +0800, Ariff Abdullah wrote:
> On Thu, 10 Aug 2006 15:51:09 +0900 (JST)
> TAMURA Kent <kent at NetBSD.org> wrote:
> > > My audio dies, espcially when my system is under heavy load.
> > > Otherwise I can maybe play music for an half hour, (with choppy
> > > sound).
> > > vendor = 'Intel Corporation'
> > > device = '82440MX AC'97 Audio Controller'
> > 440MX has a hardware erratum and an audio driver should have
> > special handling to avoid it. The drivers of NetBSD and ALSA
> > does it, and FreeBSD's does not for now.
> > ALSA:
> > http://hg-mirror.alsa-project.org/alsa-kernel?cmd=changeset;node=e0d1f8060d20;style=gitweb
> > NetBSD:
> > http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=19919
> > http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/pci/auich.c.diff?r1=1.33&r2=1.34
> Looks trivial enough, though both BUS_DMA_NOCACHE/COHERENT almost a
> noop for most FreeBSD archs. I'll revisit this sooner using other
> non-cacheable method.
AFAIK arm/sparc64 has implemented BUS_DMA_COHERENT. But it seems that
BUS_DMA_COHERENT for sparc64 implementation is not complete.
What makes me wonder is why NetBSD needed an additional BUS_DMA_NOCACHE
flag as the purpose of BUS_DMA_COHERENT is to map pages into
uncached address space or to set cache-inhibit bits in PTE.
Btw, the workaround suggested by Intel said it _reduces_ the frequency
of the failure(Master Abort). Because it does not remove the bug I
wonder how it works well in real hardware.
More information about the freebsd-multimedia