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