[alsa-devel] Issue with creative Xfi PCIe ca0110-IBG
Guillem Solà
garanda at flumotion.com
Tue Oct 13 11:59:14 CEST 2009
Takashi Iwai wrote:
> At Tue, 13 Oct 2009 10:48:48 +0200,
> Guillem Solà wrote:
>
>> Takashi Iwai wrote:
>>
>>> At Fri, 09 Oct 2009 18:05:28 +0200,
>>> Guillem Solà wrote:
>>>
>>>
>>>> Takashi Iwai wrote:
>>>>
>>>>
>>>>> At Fri, 09 Oct 2009 16:15:00 +0200,
>>>>> Guillem Solà wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Takashi Iwai wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> At Fri, 09 Oct 2009 11:19:04 +0200,
>>>>>>> Guillem Solà wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have a Creative XFi PCIe with ca0110-IBG chip. It's primary use is
>>>>>>>> audio input for streaming on a brand new Dell server with RHEL. I have
>>>>>>>> been testing latest kernel 2.6.31 through it's releases candidates and
>>>>>>>> the card stoped working on 2.6.31-rc6, so now I'm stuck at 2.6.31-rc5.
>>>>>>>> With rc5 I made a 2 weeks test and it went flawlessly.
>>>>>>>>
>>>>>>>> There's another guy who referenced this issue on
>>>>>>>> http://mailman.alsa-project.org/pipermail/alsa-devel/2009-September/020876.html
>>>>>>>> and Takashi Iwai said that there is a communication error between the
>>>>>>>> codec and the controller.
>>>>>>>>
>>>>>>>> Any workaround? Is there a bug created related to this issue?
>>>>>>>>
>>>>>>>> I tried to "extract" the alsa-driver on 2.6.31-rc5 and install it 2.6.31
>>>>>>>> final without success. Also tried to get old snapshots from alsa-driver
>>>>>>>> and alsa-kmirror but I cannot compile them. Any place where get some
>>>>>>>> info about how to create
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> Then some codes added after rc5 regressed?
>>>>>>> The candidates are not so many but a few:
>>>>>>>
>>>>>>> deadff1665491afce124a8ff83f00f784161f660
>>>>>>> ALSA: hda: track CIRB/CORB command/response states for each codec
>>>>>>>
>>>>>>> a678cdee25a387c8fc3b2754974695412baf1d85
>>>>>>> ALSA: hda: take cmd_mutex in probe_codec()
>>>>>>>
>>>>>>> cdb1fbf23181c133fb24f12ad14ccea7dc399599
>>>>>>> ALSA: hda: take reg_lock in azx_init_cmd_io/azx_free_cmd_io
>>>>>>>
>>>>>>> c32649feb4573b31f0a2bfdf35cbe1351256c764
>>>>>>> ALSA: hda: read CORBWP inside reg_lock
>>>>>>>
>>>>>>> feb273404f15d86098cb0e81e46330d5c1e22b1b
>>>>>>> ALSA: hda: remember last command for each codec
>>>>>>>
>>>>>>> The suspicious changes are the first one and the third one.
>>>>>>> But, anyway, it'd be helpful if you can bisect these.
>>>>>>>
>>>>>>> If you can use git, git-bisect would be the best to try.
>>>>>>> Do bisect only for changes in sound/pci/hda directory between
>>>>>>> 2.6.31-rc5 and rc6.
>>>>>>>
>>>>>>>
>>>>>>> thanks,
>>>>>>>
>>>>>>> Takashi
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Ok I read how to do bisect with git and so on. Also take latest alsa
>>>>>> from git.
>>>>>>
>>>>>> Now the question is do I have to do bisect from alsa-kernel? (that's
>>>>>> what I'm trying now) but that implies recompile kernel in every step,
>>>>>> isn't it?
>>>>>>
>>>>>>
>>>>>>
>>>>> If you can build the kernel by yourself, and you already find that
>>>>> 2.6.31-rc5 works as is, I recommend you to bisect the kernel tree.
>>>>>
>>>>> As mentioned, the commits to bisect are only for sound/pci/hda
>>>>> directory, and there aren't so many. You can just rebuild the module
>>>>> with "make M=sound/pci/hda" during bisecting.
>>>>>
>>>>>
>>>>> Takashi
>>>>> _______________________________________________
>>>>> Alsa-devel mailing list
>>>>> Alsa-devel at alsa-project.org
>>>>> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>>>>>
>>>>>
>>>>>
>>>> Ok Think I Finally get it :-)
>>>>
>>>> those are the latest steps I did, AFAIK it was the first commit after
>>>> 2.6.31-rc5 as you said "The suspicious changes are the first one and the
>>>> third one."
>>>>
>>>> deadff1665491afce124a8ff83f00f784161f660 is first bad commit
>>>>
>>>>
>>> Thanks! That's what I expected (and worried)...
>>>
>>> What happens if you apply the patch below to the latest alsa driver
>>> (or 2.6.31-rc6)?
>>>
>>>
>>> Takashi
>>>
>>> ---
>>> diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
>>> index d0effa3..81663a7 100644
>>> --- a/sound/pci/hda/hda_intel.c
>>> +++ b/sound/pci/hda/hda_intel.c
>>> @@ -566,6 +566,7 @@ static void azx_free_cmd_io(struct azx *chip)
>>>
>>> static unsigned int azx_command_addr(u32 cmd)
>>> {
>>> +#if 0 /* XXX */
>>> unsigned int addr = cmd >> 28;
>>>
>>> if (addr >= AZX_MAX_CODECS) {
>>> @@ -574,6 +575,9 @@ static unsigned int azx_command_addr(u32 cmd)
>>> }
>>>
>>> return addr;
>>> +#else
>>> + return 0;
>>> +#endif
>>> }
>>>
>>> static unsigned int azx_response_addr(u32 res)
>>> @@ -818,6 +822,7 @@ static unsigned int azx_get_response(struct hda_bus *bus,
>>> unsigned int addr)
>>> {
>>> struct azx *chip = bus->private_data;
>>> + addr = 0; /* XXX */
>>> if (chip->single_cmd)
>>> return azx_single_get_response(bus, addr);
>>> else
>>>
>>>
>>>
>> I tried the patch you have attached, it patched well (I checked it) but
>> seems to not work
>>
>> After make I tried to modprobe snd-hda-intel-ca0110 and I saw in dmesg:
>>
>> hda-intel: Invalid position buffer, using LPIB read method instead.
>> alsactl[8292]: segfault at 0 ip (null) sp bfa83f1c error 14 in
>> ld-2.5.so[54c000+1a000]
>> HDA Intel 0000:05:00.0: PCI INT A disabled
>>
>> and after reboot:
>>
>> HDA Intel 0000:05:00.0: PCI INT A -> GSI 38 (level, low) -> IRQ 38
>> hda-intel: spurious response 0x1102000a:0x1, last cmd=0x000000
>> hda-intel: azx_get_response timeout, switching to polling mode: last
>> cmd=0x100f0000
>> hda-intel: Codec #1 probe error; disabling it...
>> hda-intel: spurious response 0x1102000a:0x1, last cmd=0x000000
>> hda_intel: azx_get_response timeout, switching to single_cmd mode: last
>> cmd=0x100f0000
>> hda-intel: no codecs initialized
>> HDA Intel 0000:05:00.0: PCI INT A disabled
>>
>> It seems something went wrong
>>
>
> It's not a right fix but a band-aid. With that patch, load with
> probe_mask=0x01 option.
>
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>
uhmm... don't know if I'm doing something wrong but
modprobe snd-hda-codec-ca0110 probe_mask=0x01
says:
FATAL: Error inserting snd_hda_codec_ca0110
(/lib/modules/2.6.31-rc6/extra/snd-hda-codec-ca0110.ko): Unknown symbol
in module, or unknown parameter (see dmesg)
in dmesg
snd_hda_codec_ca0110: Unknown parameter `probe_mask'
probe_mask option isn't only for snd-hda-intel?
thanks,
Guillem Solà
More information about the Alsa-devel
mailing list