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

[Takashi Iwai]

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