At Tue, 13 Oct 2009 13:28:05 +0200,
Guillem Solà wrote:
>
> Takashi Iwai wrote:
> > At Tue, 13 Oct 2009 12:26:29 +0200,
> > Guillem Solà wrote:
> >
> >> Takashi Iwai wrote:
> >>
> >>> 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:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> 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
> >>>
> >>>
> >> I did it too without success, hda-intel seems not to load automatically
> >> snd-hda-codec-ca0110
> >>
> >> (dmesg)
> >> HDA Intel 0000:05:00.0: PCI INT A -> GSI 38 (level, low) -> IRQ 38
> >> hda-intel: no codecs initialized
> >> HDA Intel 0000:05:00.0: PCI INT A disabled
> >>
> >
> > Without the patch, which slot was detected? It's possible that the
> > h/w communication stack is already disturbed somehow...
> >
> >
> > Takashi
> >
> >
> Hi,
>
> Without the patch it seems that lspci shows the same slot, isn't it?
It's not about the PCI slot but the codec address in HD-audio bus.
> 05:00.0 Audio device: Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG
> Subsystem: Creative Labs Unknown device 0018
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+
> Stepping- SERR+ FastB2B-
> Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
> Latency: 32 (500ns min, 5000ns max)
> Interrupt: pin A routed to IRQ 38
> Region 0: Memory at df9fc000 (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-ze=16K]
> Capabilities: [dc] Power Management version 3
>
> output from alsa-info.sh
>
> http://www.alsa-project.org/db/?f=7cd29b83a727482af373c50d7d8b5e2edb10f738
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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
