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