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@xxxxxxxxxxxxxxxx > > 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 _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
