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

[Guillem Solà]

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


LOG WITH LATEST STEPS:

- HAVE TO REBOOT CANNOT GET CARD WORKING AGAIN--

- TEST - DOESN'T WORK -

# 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

- HAVE TO REBOOT CANNOT GET CARD WORKING AGAIN--

- HERE STARTS TO WORK AGAIN -

# 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



regards,

Guillem Solà