Takashi Iwai <tiwai <at> suse.de> writes: > > 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. > > Takashi > _______________________________________________ > Alsa-devel mailing list > Alsa-devel <at> alsa-project.org > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel > Hi, I have the same model of sound card and can't make it work. I saw that this conversation has stalled so I'm going to give informations about what I've tested. First thing, using one of the latest alsa-driver snapshots with a 2.6.31-gentoo-r2 kernel, I got this in dmesg when loading the snd-hda-intel driver : [ 111.287946] ACPI: PCI Interrupt Link [APC2] enabled at IRQ 17 [ 111.287968] HDA Intel 0000:03:00.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17 [ 111.567237] hda-intel: spurious response 0x0:0x0, last cmd=0x000000 [ 112.575093] hda-intel: azx_get_response timeout, switching to polling mode: last cmd=0x107f0d00 [ 113.583158] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x107f0d00 And then, when I tried to play a sound a few times : [ 167.997029] hda_codec: rates == 0 (nid=0x12, val=0x0, ovrd=0) [ 173.053323] __ratelimit: 1 callbacks suppressed [ 174.124799] hda_codec: rates == 0 (nid=0x12, val=0x0, ovrd=0) [ 287.496606] hda_codec: rates == 0 (nid=0x12, val=0x0, ovrd=0) [ 287.496934] __ratelimit: 20 callbacks suppressed I made my tests with aplay and mplayer, they just stall and I don't get any sound. Today, after reading this thread I tried making it work with the 2.6.31 kernel from rc3 to rc6 (without gentoo patches), none of them worked. I compiled them with debug and this is the output of dmesg when I load the driver : [ 1778.639675] HDA Intel 0000:03:00.0: PCI INT A -> Link[APC2] -> GSI 17 (level, low) -> IRQ 17 [ 1778.639778] ALSA sound/pci/hda/hda_intel.c:2334: chipset global capabilities = 0x3300 [ 1778.663717] ALSA sound/pci/hda/hda_intel.c:823: codec_mask = 0x2 [ 1778.663830] ALSA sound/pci/hda/hda_intel.c:1252: codec #1 probed OK [ 1778.695745] ALSA sound/pci/hda/hda_codec.c:3857: autoconfig: line_outs=4 (0xb/0xd/0xc/0xe/0x0) [ 1778.695753] ALSA sound/pci/hda/hda_codec.c:3861: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [ 1778.695760] ALSA sound/pci/hda/hda_codec.c:3865: hp_outs=1 (0xf/0x0/0x0/0x0/0x0) [ 1778.695767] ALSA sound/pci/hda/hda_codec.c:3866: mono: mono_out=0x0 [ 1778.695772] ALSA sound/pci/hda/hda_codec.c:3869: dig-out=0x12/0x0 [ 1778.695777] ALSA sound/pci/hda/hda_codec.c:3877: inputs: mic=0x11, fmic=0x0, line=0x10, fline=0x0, cd=0x0, aux=0x0 [ 1778.695785] ALSA sound/pci/hda/hda_codec.c:3879: dig-in=0x13 And when I try to play a sound : [ 1845.100435] ALSA sound/pci/hda/hda_intel.c:1557: azx_pcm_prepare: bufsize=0x8000, format=0x13 [ 1845.100457] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x12 [ 1845.100466] ALSA sound/pci/hda/hda_codec.c:1063: hda_codec_setup_stream: NID=0x2, stream=0x4, channel=0, format=0x13 [ 1845.108003] ALSA sound/pci/hda/hda_codec.c:1063: hda_codec_setup_stream: NID=0x6, stream=0x4, channel=0, format=0x13 [ 1845.116000] ALSA sound/pci/hda/hda_codec.c:1063: hda_codec_setup_stream: NID=0x4, stream=0x4, channel=2, format=0x13 [ 1845.124001] ALSA sound/pci/hda/hda_codec.c:1063: hda_codec_setup_stream: NID=0x3, stream=0x4, channel=0, format=0x13 [ 1845.132001] ALSA sound/pci/hda/hda_codec.c:1063: hda_codec_setup_stream: NID=0x5, stream=0x4, channel=0, format=0x13 [ 1851.730678] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x2 [ 1851.730691] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x4 [ 1851.730705] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x3 [ 1851.730717] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x5 [ 1851.730724] ALSA sound/pci/hda/hda_codec.c:1076: hda_codec_cleanup_stream: NID=0x6 I tried using your patch Takashi, the driver wouldn't load until I put 1 in the address like Guillem did. But even with that sound doesn't work no matter the probe_mask setting I use. And a last note, I did my tests on the rc versions without rebooting, just removing the module and modprobing it again, but I don't think it matters. Here's my lspci -vvnn : 02:00.0 PCI bridge [0604]: Creative Labs Device [1102:7006] (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Bus: primary=02, secondary=03, subordinate=03, sec-latency=32 Memory behind bridge: fdf00000-fdffffff Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Bridge: PM- B3+ Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Count=1/16 Enable- Address: 0000000000000000 Data: 0000 Capabilities: [80] Subsystem: Creative Labs Device [1102:0010] Capabilities: [90] Express (v1) PCI/PCI-X Bridge, MSI 00 DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <4us, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ BrConfRtry- MaxPayload 512 bytes, MaxReadReq 512 bytes DevSta: CorrErr- UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <1us, L1 <16us ClockPM- Suprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [100] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSVoil- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSVoil- UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSVoil- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr- AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn- 03:00.0 Audio device [0403]: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG [1102:0009] Subsystem: Creative Labs Device [1102:0018] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 32 (500ns min, 5000ns max) Interrupt: pin A routed to IRQ 17 Region 0: Memory at fdffc000 (32-bit, non-prefetchable) [size=16K] Capabilities: [dc] Power Management version 3 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel Output from alsa-info : http://www.alsa-project.org/db/?f=473df043d8633b85a0a5319d2e7a73c4a13d2761 Hope this gives you some hint to solve our problem. Regards, Philippe _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
