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:

...

Takashi Iwai wrote:

...

At Fri, 09 Oct 2009 11:19:04 +0200, Guillem Solà wrote:

...

Hi,

I have a Creative XFi PCIe with ca0110-IBG chip. It's primary use is audio input for streaming on a brand new Dell server with RHEL. I have been testing latest kernel 2.6.31 through it's releases candidates and the card stoped working on 2.6.31-rc6, so now I'm stuck at 2.6.31-rc5. With rc5 I made a 2 weeks test and it went flawlessly.

There's another guy who referenced this issue on http://mailman.alsa-project.org/pipermail/alsa-devel/2009-September/020876.h... and Takashi Iwai said that there is a communication error between the codec and the controller.

Any workaround? Is there a bug created related to this issue?

I tried to "extract" the alsa-driver on 2.6.31-rc5 and install it 2.6.31 final without success. Also tried to get old snapshots from alsa-driver and alsa-kmirror but I cannot compile them. Any place where get some info about how to create

Then some codes added after rc5 regressed? The candidates are not so many but a few:

deadff1665491afce124a8ff83f00f784161f660 ALSA: hda: track CIRB/CORB command/response states for each codec

a678cdee25a387c8fc3b2754974695412baf1d85 ALSA: hda: take cmd_mutex in probe_codec()

cdb1fbf23181c133fb24f12ad14ccea7dc399599 ALSA: hda: take reg_lock in azx_init_cmd_io/azx_free_cmd_io

c32649feb4573b31f0a2bfdf35cbe1351256c764 ALSA: hda: read CORBWP inside reg_lock

feb273404f15d86098cb0e81e46330d5c1e22b1b ALSA: hda: remember last command for each codec

The suspicious changes are the first one and the third one. But, anyway, it'd be helpful if you can bisect these.

If you can use git, git-bisect would be the best to try. Do bisect only for changes in sound/pci/hda directory between 2.6.31-rc5 and rc6.

thanks,

Takashi

Ok I read how to do bisect with git and so on. Also take latest alsa from git.

Now the question is do I have to do bisect from alsa-kernel? (that's what I'm trying now) but that implies recompile kernel in every step, isn't it?

If you can build the kernel by yourself, and you already find that 2.6.31-rc5 works as is, I recommend you to bisect the kernel tree.

As mentioned, the commits to bisect are only for sound/pci/hda directory, and there aren't so many. You can just rebuild the module with "make M=sound/pci/hda" during bisecting.

Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

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:

...

Takashi Iwai wrote:

...

At Fri, 09 Oct 2009 11:19:04 +0200, Guillem Solà wrote:

> Hi, > > I have a Creative XFi PCIe with ca0110-IBG chip. It's primary use is > audio input for streaming on a brand new Dell server with RHEL. I have > been testing latest kernel 2.6.31 through it's releases candidates and > the card stoped working on 2.6.31-rc6, so now I'm stuck at 2.6.31-rc5. > With rc5 I made a 2 weeks test and it went flawlessly. > > There's another guy who referenced this issue on > http://mailman.alsa-project.org/pipermail/alsa-devel/2009-September/020876.h... > and Takashi Iwai said that there is a communication error between the > codec and the controller. > > Any workaround? Is there a bug created related to this issue? > > I tried to "extract" the alsa-driver on 2.6.31-rc5 and install it 2.6.31 > final without success. Also tried to get old snapshots from alsa-driver > and alsa-kmirror but I cannot compile them. Any place where get some > info about how to create > > > Then some codes added after rc5 regressed? The candidates are not so many but a few:

deadff1665491afce124a8ff83f00f784161f660 ALSA: hda: track CIRB/CORB command/response states for each codec

a678cdee25a387c8fc3b2754974695412baf1d85 ALSA: hda: take cmd_mutex in probe_codec()

cdb1fbf23181c133fb24f12ad14ccea7dc399599 ALSA: hda: take reg_lock in azx_init_cmd_io/azx_free_cmd_io

c32649feb4573b31f0a2bfdf35cbe1351256c764 ALSA: hda: read CORBWP inside reg_lock

feb273404f15d86098cb0e81e46330d5c1e22b1b ALSA: hda: remember last command for each codec

The suspicious changes are the first one and the third one. But, anyway, it'd be helpful if you can bisect these.

If you can use git, git-bisect would be the best to try. Do bisect only for changes in sound/pci/hda directory between 2.6.31-rc5 and rc6.

thanks,

Takashi

Ok I read how to do bisect with git and so on. Also take latest alsa from git.

Now the question is do I have to do bisect from alsa-kernel? (that's what I'm trying now) but that implies recompile kernel in every step, isn't it?

If you can build the kernel by yourself, and you already find that 2.6.31-rc5 works as is, I recommend you to bisect the kernel tree.

As mentioned, the commits to bisect are only for sound/pci/hda directory, and there aren't so many. You can just rebuild the module with "make M=sound/pci/hda" during bisecting.

Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

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:

> Takashi Iwai wrote: > > > >> At Fri, 09 Oct 2009 11:19:04 +0200, >> Guillem Solà wrote: >> >> >> >> >>> Hi, >>> >>> I have a Creative XFi PCIe with ca0110-IBG chip. It's primary use is >>> audio input for streaming on a brand new Dell server with RHEL. I have >>> been testing latest kernel 2.6.31 through it's releases candidates and >>> the card stoped working on 2.6.31-rc6, so now I'm stuck at 2.6.31-rc5. >>> With rc5 I made a 2 weeks test and it went flawlessly. >>> >>> There's another guy who referenced this issue on >>> http://mailman.alsa-project.org/pipermail/alsa-devel/2009-September/020876.h... >>> and Takashi Iwai said that there is a communication error between the >>> codec and the controller. >>> >>> Any workaround? Is there a bug created related to this issue? >>> >>> I tried to "extract" the alsa-driver on 2.6.31-rc5 and install it 2.6.31 >>> final without success. Also tried to get old snapshots from alsa-driver >>> and alsa-kmirror but I cannot compile them. Any place where get some >>> info about how to create >>> >>> >>> >>> >> Then some codes added after rc5 regressed? >> The candidates are not so many but a few: >> >> deadff1665491afce124a8ff83f00f784161f660 >> ALSA: hda: track CIRB/CORB command/response states for each codec >> >> a678cdee25a387c8fc3b2754974695412baf1d85 >> ALSA: hda: take cmd_mutex in probe_codec() >> >> cdb1fbf23181c133fb24f12ad14ccea7dc399599 >> ALSA: hda: take reg_lock in azx_init_cmd_io/azx_free_cmd_io >> >> c32649feb4573b31f0a2bfdf35cbe1351256c764 >> ALSA: hda: read CORBWP inside reg_lock >> >> feb273404f15d86098cb0e81e46330d5c1e22b1b >> ALSA: hda: remember last command for each codec >> >> The suspicious changes are the first one and the third one. >> But, anyway, it'd be helpful if you can bisect these. >> >> If you can use git, git-bisect would be the best to try. >> Do bisect only for changes in sound/pci/hda directory between >> 2.6.31-rc5 and rc6. >> >> >> thanks, >> >> Takashi >> >> >> >> >> > Ok I read how to do bisect with git and so on. Also take latest alsa > from git. > > Now the question is do I have to do bisect from alsa-kernel? (that's > what I'm trying now) but that implies recompile kernel in every step, > isn't it? > > > If you can build the kernel by yourself, and you already find that 2.6.31-rc5 works as is, I recommend you to bisect the kernel tree.

As mentioned, the commits to bisect are only for sound/pci/hda directory, and there aren't so many. You can just rebuild the module with "make M=sound/pci/hda" during bisecting.

Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

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

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

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

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

--- diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index c9ad182..50dd28b 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -2264,6 +2264,8 @@ static struct snd_pci_quirk probe_mask_list[] __devinitdata = { SND_PCI_QUIRK(0x17aa, 0x20ac, "Thinkpad X/T/R61", 0x01), /* broken BIOS */ SND_PCI_QUIRK(0x1028, 0x20ac, "Dell Studio Desktop", 0x01), + /* CA0110-IBG: causes errors when other slots accessed */ + SND_PCI_QUIRK(0x1102, 0x0018, "SB X-Fi Xtreme Audio", 0x02), /* including bogus ALC268 in slot#2 that conflicts with ALC888 */ SND_PCI_QUIRK(0x17c0, 0x4085, "Medion MD96630", 0x01), /* forced codec slots */