[alsa-devel] Issue with creative Xfi PCIe ca0110-IBG

Guillem Solà garanda at flumotion.com
Fri Oct 9 18:05:28 CEST 2009

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

an there are no more after that




# git bisect bad
Bisecting: 0 revisions left to test after this
[ce577e8cf5ddb4216553c9d563a9835d6de70ffa] ALSA: hda - Fix quirk for 
Toshiba Satellite A135-S4527

# /etc/init.d/alsasound stop
# rmmod snd_page_alloc
# make M=sound/pci/hda
# make modules_install M=sound/pci/hda
# modprobe snd-hda-codec-ca0110



# git bisect good
deadff1665491afce124a8ff83f00f784161f660 is first bad commit
commit deadff1665491afce124a8ff83f00f784161f660
Author: Wu Fengguang <fengguang.wu at intel.com>
Date:   Sat Aug 1 18:45:16 2009 +0800

    ALSA: hda: track CIRB/CORB command/response states for each codec
    Recently we hit a bug in our dev board, whose HDMI codec#3 may emit
    redundant/spurious responses, which were then taken as responses to
    command for another onboard Realtek codec#2, and mess up both codecs.
    Extend the azx_rb.cmds and azx_rb.res to array and track each codec's
    commands/responses separately. This helps keep good codec safe from
    broken ones.
    Signed-off-by: Wu Fengguang <fengguang.wu at intel.com>
    Signed-off-by: Takashi Iwai <tiwai at suse.de>

:040000 040000 344e29e487277ab9354ab4b44e127f0ae906cf8c 
411a475d6307af6021f0882d1dfee6bdb18b66b6 M    sound


Guillem Solà

More information about the Alsa-devel mailing list