Date: Tue, 6 Apr 2010 03:39:17 -0700 From: Garrett Cooper <yanefbsd@gmail.com> To: multimedia@freebsd.org Subject: Re: Buzzing snd_emu10kx enabled card with r206173 Message-ID: <p2v7d6fde3d1004060339nfdbc4cb9p9ac6e232e38b4d6@mail.gmail.com> In-Reply-To: <x2m7d6fde3d1004051226k7a0e350bz579b899e4fedd977@mail.gmail.com> References: <u2q7d6fde3d1004051122madc6ebb4jc3248d8c68a81333@mail.gmail.com> <x2m7d6fde3d1004051226k7a0e350bz579b899e4fedd977@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 5, 2010 at 12:26 PM, Garrett Cooper <yanefbsd@gmail.com> wrote: > On Mon, Apr 5, 2010 at 11:22 AM, Garrett Cooper <yanefbsd@gmail.com> wrot= e: >> Hi, >> =A0 =A0When I first installed FreeBSD on this machine, I had a heck of a >> time getting the soundcard's PCM channel to function properly. It >> would buzz incessantly when I played any audio on it; I disabled the >> onboard snd_hda enabled audio and things magically worked, until >> today. After a kernel upgrade and a few warm boots, I'm back to where >> I started from -- the PCM channel buzzes whenever I play audio; >> line-in works perfectly fine however. I'm not seeing anything out of >> the ordinary in commits over the past couple of weeks for the pcm >> pieces (the last successful kernel I used was 2~3 weeks old). >> =A0 =A0Are there any device_printf's I should add or a debug procedure >> that you recommend I do to triage the situation? >> Thanks, >> -Garrett >> >> # uname -a >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206173M: >> Sun Apr =A04 19:54:22 PDT 2010 >> root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA =A0amd64 >> # pciconf -lv | grep -A 4 emu >> emu10kx0@pci0:8:0:0: =A0 =A0class=3D0x040100 card=3D0x10211102 chip=3D0x= 00081102 >> rev=3D0x00 hdr=3D0x00 >> =A0 =A0vendor =A0 =A0 =3D 'Creative Technology LTD.' >> =A0 =A0device =A0 =A0 =3D 'sound blaster Audigy 2 (ca0108)' >> =A0 =A0class =A0 =A0 =A0=3D multimedia >> =A0 =A0subclass =A0 =3D audio >> # dmesg | grep 'irq 16' >> uhci0: <Intel 82801JI (ICH10) USB controller USB-D> port 0xa800-0xa81f >> irq 16 at device 26.0 on pci0 >> pcib7: <ACPI PCI-PCI bridge> irq 16 at device 28.1 on pci0 >> emu10kx0: <Creative Audigy 4 [SB0610]> port 0xec00-0xec3f irq 16 at >> device 0.0 on pci8 >> # dmesg | grep 'pcm' >> pcm0: <EMU10Kx DSP front PCM interface> on emu10kx0 >> pcm0: <SigmaTel STAC9750/51 AC97 Codec> >> pcm1: <EMU10Kx DSP rear PCM interface> on emu10kx0 >> pcm2: <EMU10Kx DSP center PCM interface> on emu10kx0 >> pcm3: <EMU10Kx DSP subwoofer PCM interface> on emu10kx0 >> pcm4: <EMU10Kx DSP side PCM interface> on emu10kx0 > > Some more information: > > 1. snd_emu10kx and sound are both modules loaded on boot, along with > if_re, linux, and nvidia. > 2. Disabling nvidia -> no change. > 3. Disabling acpi -> unbootable system because many drivers can't map > interrupts without it (can't test unless I isolate the drivers and > enable them one by one -- something I'll try later on). > > I'm at a loss right now... my hunch is that it's potentially a bad > interaction between the snd_emu10kx driver and another driver on the > same PCI bus (which is just the ACPI and uhci drivers), but I can't > test these claims. There are other funky things about my system that > have changed over the past couple of kernel versions, like front USB > ports could charge my iPhone, and now they don't... and the fact that > ACPI blanking via nvidia now works again... so something may have > changed on the backend, but I'm not 100% sure on what I should isolate > as the root cause, yet. Grr... it's `healed' itself again. I'll watch out for potential catalysts to the issue in the future. Thanks, -Garrett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p2v7d6fde3d1004060339nfdbc4cb9p9ac6e232e38b4d6>