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

Takashi Iwai tiwai at suse.de
Tue Oct 13 12:06:53 CEST 2009


At Tue, 13 Oct 2009 11:59:14 +0200,
Guillem Solà wrote:
> 
> 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?

Yes.  Load it like

	modprobe snd-hda-intel probe_mask=0x01

The codec modules will be loaded automatically by that.


Takashi


More information about the Alsa-devel mailing list