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@alsa-project.org 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@alsa-project.org 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