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à