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

[Guillem Solà]

Takashi Iwai wrote:
> At Wed, 14 Oct 2009 18:03:15 +0200,
> Guillem Solà wrote:
>   
>> Takashi Iwai wrote:
>>     
>>> At Tue, 13 Oct 2009 18:59:23 +0200,
>>> Guillem Solà wrote:
>>>   
>>>       
>>>> Takashi Iwai wrote:
>>>>     
>>>>         
>>>>> At Tue, 13 Oct 2009 17:01:35 +0200,
>>>>> Guillem Solà wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Takashi Iwai wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> At Tue, 13 Oct 2009 16:12:47 +0200,
>>>>>>> Guillem Solà wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> Takashi Iwai wrote:
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> At Tue, 13 Oct 2009 14:10:44 +0200,
>>>>>>>>> Guillem Solà wrote:
>>>>>>>>>   
>>>>>>>>>      
>>>>>>>>>                   
>>>>>>>>>> Takashi Iwai wrote:
>>>>>>>>>>     
>>>>>>>>>>                
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>>>> It shows the address 1.  So, my patch doesn't work, as it assumes
>>>>>>>>>>> address 0.  Replace it with 1, and pass probe_mask=0x02.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Takashi
>>>>>>>>>>>
>>>>>>>>>>>           
>>>>>>>>>>>                   
>>>>>>>>>>>                       
>>>>>>>>>> Yeah great, it's working again!
>>>>>>>>>>
>>>>>>>>>> I did modprobe snd-hda-intel probe_mask=0x03 instead of mask=0x02 to 
>>>>>>>>>> make it work
>>>>>>>>>>
>>>>>>>>>> and the patch let this way ( I changed both return 1 and addr=1)
>>>>>>>>>>     
>>>>>>>>>>         
>>>>>>>>>>             
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>> Now the question is whether probe_mask=0x03 (or 0x02) works without
>>>>>>>>> this patch.  How is it?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> thanks,
>>>>>>>>>
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> after few tests I can conclude that it could work with and without the 
>>>>>>>> patch. The same happens with modprobe snd-hda-intel probe_mask=0x03 or 
>>>>>>>> 0x02 both can work.
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> OK, good to hear.
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> So it seems to be fickle because not all the times you modprobe the 
>>>>>>>> intel module it worked.
>>>>>>>>     
>>>>>>>>             
>>>>>>>>                 
>>>>>>> Do you mean it's still unstable even with probe_mask option, or it is
>>>>>>> when without?
>>>>>>>
>>>>>>> If probe_mask fixes its fickleness (or flirtation :), the patch below
>>>>>>> should help.  It will set the default probe_mask for your device.
>>>>>>> Give it a try.
>>>>>>>
>>>>>>>
>>>>>>> Takashi
>>>>>>>           
>>>>>>>               
>>>>>> Hi,
>>>>>>
>>>>>> By fickle I mean that when modprobing hda-intel module sometimes it 
>>>>>> works fine and others cannot get audio although the system seems to 
>>>>>> always recognize the card, and yes, I'm always using probe_mask=0x02 option.
>>>>>>
>>>>>> Actually, about one of five times I can successfully load the module. As 
>>>>>> I said the first patch doesn't affect, it has been only the casualty 
>>>>>> that made me believe it did something.
>>>>>>    
>>>>>>         
>>>>>>             
>>>>> Hm, then it's still puzzling what causes the problem in the recent
>>>>> kernel.  Or is it coincidence?
>>>>>
>>>>>       
>>>>>           
>>>> Uff, really don't know what to say, when I thought I saw some light... 
>>>> I've been testing with 2.6.31-rc6 and 2.6.31 (final) with and without 
>>>> patches and maybe is only the probe_mask option what make it work sometimes.
>>>>
>>>> Perhaps I did bisect bad and wasn't 
>>>> deadff1665491afce124a8ff83f00f784161f660 first bad commit?
>>>>     
>>>>         
>>> Possible.  But, before bisecting, we should be really sure which
>>> release was really OK.  Did 2.6.30 work without any problems?
>>>
>>>   
>>>       
>> Hi,
>>
>> AFAIK in 2.6.30 ca0110 was not implemented. I see it start working in 
>> 2.6.31-rc3 and did a two weeks running test with 2.6.31-rc5.
>>
>> So I bisected from 2.6.31-rc6 to 2.6.31-rc5
>>     
>
> OK.  It's possible that a regression occurs at rc6 because of the
> core HD-audio changes.  But, I still wonder why the patch doesn't
> change anything.
>
> At least, it'd be nice if you can reconfirm that rc5 is really working
> stably.  You can just copy sound/pci/hda/* over any newer kernels.
>
>
>   

Yes, rc5 works ok. I've also copied it's hda/* to 2.6.31 final and also 
works well too.

I did the same with 2.6.32.rc2 but I cannot load the snd-hda-intel 
module because it's
complaining about what seems some incompatibilities.

snd_hda_codec: disagrees about version of symbol snd_iprintf
snd_hda_codec: Unknown symbol snd_iprintf
snd_hda_intel: Unknown symbol snd_hda_bus_new
snd_hda_intel: Unknown symbol snd_hda_build_pcms
snd_hda_intel: Unknown symbol snd_hda_codec_new
snd_hda_intel: Unknown symbol snd_hda_queue_unsol_event
snd_hda_intel: Unknown symbol snd_hda_calc_stream_format
snd_hda_intel: Unknown symbol snd_hda_suspend
snd_hda_intel: Unknown symbol snd_hda_resume
snd_hda_intel: Unknown symbol snd_hda_build_controls

regards,

Guillem Solà