On Tue, May 25, 2010 at 3:06 AM, Mark Stapper <stark@mapper.nl>
wrote:> On 18/05/2010 08:14, Mark Stapper wrote:
>> On 18/05/2010 00:22, Garrett Cooper wrote:
>>
>>> On Mon, May 17, 2010 at 11:21 AM, Mark Stapper
<stark@mapper.nl> wrote:
>>>
>>>
>>>> On 12/04/2010 16:29, Garrett Cooper wrote:
>>>>
>>>>
>>>>> On Tue, Apr 6, 2010 at 3:39 AM, Garrett Cooper
<yanefbsd@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> 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> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>> ? ?When 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).
>>>>>>>> ? ?Are 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 ?4 19:54:22 PDT 2010
>>>>>>>>
root@bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA ?amd64
>>>>>>>> # pciconf -lv | grep -A 4 emu
>>>>>>>> emu10kx0@pci0:8:0:0: ? ?class=0x040100
card=0x10211102 chip=0x00081102
>>>>>>>> rev=0x00 hdr=0x00
>>>>>>>> ? ?vendor ? ? = 'Creative Technology
LTD.'
>>>>>>>> ? ?device ? ? = 'sound blaster Audigy 2
(ca0108)'
>>>>>>>> ? ?class ? ? ?= multimedia
>>>>>>>> ? ?subclass ? = 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.
>>>>>>
>>>>>>
>>>>>>
>>>>> ? ? Ok. Damn issue came back and here's what happened.
Rebooted
>>>>> several times with the same kernel and slight
modifications, loading
>>>>> and unloading snd_emu10kx and sound, testing out
snd_emu10k1, and no
>>>>> dice. The buzz was bad and it was driving me insane. Again,
line-in
>>>>> functioned just fine, so I didn't know what the heck
was going. I was
>>>>> getting desperate, so I finally broke down and booted the
Gentoo Linux
>>>>> livecd. PCM worked just fine. Then I got irritated enough
and finally
>>>>> just built the module and the sound support directly into
the kernel
>>>>> and everything is hunky dorey again. Does anyone have a
stab in the
>>>>> dark as to what's going on? Is it a potential bus or
interrupt
>>>>> conflict / race condition that gets alleviated when support
is nailed
>>>>> into the kernel? Or are other folks as stumped as I am,
s.t. I should
>>>>> just try emailing current@ instead to see if someone maybe
knows
>>>>> what's going on there :(...?
>>>>> Thanks,
>>>>> -Garrett
>>>>>
>>>>>
>>>> I have the same problem.
>>>> I'll try compiling the driver in the kernel.
>>>>
>>>>
>>> ? ? FWIW I've compiled the driver into the kernel for several
>>> iterations now and it works like a champ, so there's something
with
>>> the sound subsystem that isn't jiving properly when loading
from
>>> modules...
>>> HTH,
>>> -Garrett
>>>
>>>
>> Thanks for the info.
>> I've noticed that when I load the kernel module at startup (by
adding it
>> to loader.conf) chances of it working improve.
>> If I load it afterwards, the nice huff puff sounds come out of my
>> speaker again.
>> Compiling the new and improved kernel today.
>> Thanks for your help.
>> Greetz,
>> Mark
>>
>>
> I compiled the emu10kx driver into the kernel.
> That seemed to work, but now the hissing and buzzing is back.
> I really don't know what is going on anymore..
> Any thoughts?
What modules have you compiled and loaded?
Thanks,
-Garrett