Takashi Iwai wrote: > At Wed, 14 Oct 2009 18:03:15 +0200, > Guillem Solà wrote: > >> Takashi Iwai wrote: >> >>> At Tue, 13 Oct 2009 18:59:23 +0200, >>> Guillem Solà wrote: >>> >>> >>>> Takashi Iwai wrote: >>>> >>>> >>>>> At Tue, 13 Oct 2009 17:01:35 +0200, >>>>> Guillem Solà wrote: >>>>> >>>>> >>>>> >>>>>> Takashi Iwai wrote: >>>>>> >>>>>> >>>>>> >>>>>>> At Tue, 13 Oct 2009 16:12:47 +0200, >>>>>>> Guillem Solà wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Takashi Iwai wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> At Tue, 13 Oct 2009 14:10:44 +0200, >>>>>>>>> Guillem Solà wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Takashi Iwai wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> It shows the address 1. So, my patch doesn't work, as it assumes >>>>>>>>>>> address 0. Replace it with 1, and pass probe_mask=0x02. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Takashi >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Yeah great, it's working again! >>>>>>>>>> >>>>>>>>>> I did modprobe snd-hda-intel probe_mask=0x03 instead of mask=0x02 to >>>>>>>>>> make it work >>>>>>>>>> >>>>>>>>>> and the patch let this way ( I changed both return 1 and addr=1) >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Now the question is whether probe_mask=0x03 (or 0x02) works without >>>>>>>>> this patch. How is it? >>>>>>>>> >>>>>>>>> >>>>>>>>> thanks, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> after few tests I can conclude that it could work with and without the >>>>>>>> patch. The same happens with modprobe snd-hda-intel probe_mask=0x03 or >>>>>>>> 0x02 both can work. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> OK, good to hear. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> So it seems to be fickle because not all the times you modprobe the >>>>>>>> intel module it worked. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Do you mean it's still unstable even with probe_mask option, or it is >>>>>>> when without? >>>>>>> >>>>>>> If probe_mask fixes its fickleness (or flirtation :), the patch below >>>>>>> should help. It will set the default probe_mask for your device. >>>>>>> Give it a try. >>>>>>> >>>>>>> >>>>>>> Takashi >>>>>>> >>>>>>> >>>>>> Hi, >>>>>> >>>>>> By fickle I mean that when modprobing hda-intel module sometimes it >>>>>> works fine and others cannot get audio although the system seems to >>>>>> always recognize the card, and yes, I'm always using probe_mask=0x02 option. >>>>>> >>>>>> Actually, about one of five times I can successfully load the module. As >>>>>> I said the first patch doesn't affect, it has been only the casualty >>>>>> that made me believe it did something. >>>>>> >>>>>> >>>>>> >>>>> Hm, then it's still puzzling what causes the problem in the recent >>>>> kernel. Or is it coincidence? >>>>> >>>>> >>>>> >>>> Uff, really don't know what to say, when I thought I saw some light... >>>> I've been testing with 2.6.31-rc6 and 2.6.31 (final) with and without >>>> patches and maybe is only the probe_mask option what make it work sometimes. >>>> >>>> Perhaps I did bisect bad and wasn't >>>> deadff1665491afce124a8ff83f00f784161f660 first bad commit? >>>> >>>> >>> Possible. But, before bisecting, we should be really sure which >>> release was really OK. Did 2.6.30 work without any problems? >>> >>> >>> >> Hi, >> >> AFAIK in 2.6.30 ca0110 was not implemented. I see it start working in >> 2.6.31-rc3 and did a two weeks running test with 2.6.31-rc5. >> >> So I bisected from 2.6.31-rc6 to 2.6.31-rc5 >> > > OK. It's possible that a regression occurs at rc6 because of the > core HD-audio changes. But, I still wonder why the patch doesn't > change anything. > > At least, it'd be nice if you can reconfirm that rc5 is really working > stably. You can just copy sound/pci/hda/* over any newer kernels. > > > Yes, rc5 works ok. I've also copied it's hda/* to 2.6.31 final and also works well too. I did the same with 2.6.32.rc2 but I cannot load the snd-hda-intel module because it's complaining about what seems some incompatibilities. snd_hda_codec: disagrees about version of symbol snd_iprintf snd_hda_codec: Unknown symbol snd_iprintf snd_hda_intel: Unknown symbol snd_hda_bus_new snd_hda_intel: Unknown symbol snd_hda_build_pcms snd_hda_intel: Unknown symbol snd_hda_codec_new snd_hda_intel: Unknown symbol snd_hda_queue_unsol_event snd_hda_intel: Unknown symbol snd_hda_calc_stream_format snd_hda_intel: Unknown symbol snd_hda_suspend snd_hda_intel: Unknown symbol snd_hda_resume snd_hda_intel: Unknown symbol snd_hda_build_controls regards, Guillem Solà _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
