Re: Issue with creative Xfi PCIe ca0110-IBG

["Guillem Solà" <garanda@flumotion.com>]

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@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

regards,

Guillem Solà
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel