Issue with creative Xfi PCIe ca0110-IBG

Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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.html 
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

my output from alsa-info:

http://www.alsa-project.org/db/?f=09087914dfdd85a07dca432cf71a9626b4fc4251

regards,

Guillem Solà

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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.html 
> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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.html 
>> 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?

thanks,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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.html 
> >> 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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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.html 
>>>> 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
>   
Thanks for all,

This is a log about how is it going. I think I'm doing things right.

I have to reboot every time because I cannot get the soundcard work again.

I started from 2.6.31-rc6, compiled and installed it and then reboot to 
my 2.6.31-rc6 from git.


# git bisect start -- sound/pci/hda/
# git bisect good v2.6.31-rc5
# git bisect bad
Bisecting: 6 revisions left to test after this
[feb273404f15d86098cb0e81e46330d5c1e22b1b] ALSA: hda: remember last 
command for each codec
-- HAVE TO REBOOT --
# make M=sound/pci/hda
# make modules_install M=sound/pci/hda

# /etc/init.d/alsasound stop
# rmmod snd_hda_codec_ca0110
# rmmod snd_hda_codec
# /etc/init.d/alsasound start

- HAVE TO REBOOT CANNOT GET CARD WORKING AGAIN--

# git bisect log
git bisect start 'sound/pci/hda/'
# good: [ed680c4ad478d0fee9740f7d029087f181346564] Linux 2.6.31-rc5
git bisect good ed680c4ad478d0fee9740f7d029087f181346564
# bad: [64f1607ffbbc772685733ea63e6f7f4183df1b16] Linux 2.6.31-rc6
git bisect bad 64f1607ffbbc772685733ea63e6f7f4183df1b16

# git bisect bad
Bisecting: 2 revisions left to test after this
[a678cdee25a387c8fc3b2754974695412baf1d85] ALSA: hda: take cmd_mutex in 
probe_codec()

# /etc/init.d/alsasound stop
# make modules_install M=sound/pci/hda
# /etc/init.d/alsasound start
# /etc/init.d/alsasound stop
# modprobe snd-hda-codec-ca0110
# /etc/init.d/alsasound start

- HAVE TO REBOOT CANNOT GET CARD WORKING AGAIN--
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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.html 
>>>> 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

an there are no more after that


LOG WITH LATEST STEPS:

- HAVE TO REBOOT CANNOT GET CARD WORKING AGAIN--

- TEST - DOESN'T WORK -

# git bisect bad
Bisecting: 0 revisions left to test after this
[ce577e8cf5ddb4216553c9d563a9835d6de70ffa] ALSA: hda - Fix quirk for 
Toshiba Satellite A135-S4527

# /etc/init.d/alsasound stop
# rmmod snd_page_alloc
# make M=sound/pci/hda
# make modules_install M=sound/pci/hda
# modprobe snd-hda-codec-ca0110

- HAVE TO REBOOT CANNOT GET CARD WORKING AGAIN--

- HERE STARTS TO WORK AGAIN -

# git bisect good
deadff1665491afce124a8ff83f00f784161f660 is first bad commit
commit deadff1665491afce124a8ff83f00f784161f660
Author: Wu Fengguang <fengguang.wu@intel.com>
Date:   Sat Aug 1 18:45:16 2009 +0800

    ALSA: hda: track CIRB/CORB command/response states for each codec
   
    Recently we hit a bug in our dev board, whose HDMI codec#3 may emit
    redundant/spurious responses, which were then taken as responses to
    command for another onboard Realtek codec#2, and mess up both codecs.
   
    Extend the azx_rb.cmds and azx_rb.res to array and track each codec's
    commands/responses separately. This helps keep good codec safe from
    broken ones.
   
    Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

:040000 040000 344e29e487277ab9354ab4b44e127f0ae906cf8c 
411a475d6307af6021f0882d1dfee6bdb18b66b6 M    sound



regards,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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.html 
> >>>> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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.html 
>>>>>> 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

regards,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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.html 
> >>>>>> 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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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.html 
>>>>>>>> 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?

thanks,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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.html 
> >>>>>>>> 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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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

thanks,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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?

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

thanks,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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)

---
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.cazx_single_get_response(bus, addr);
     else
@@ -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 1;
+#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 = 1; /* XXX */
     if (chip->single_cmd)
         return azx_single_get_response(bus, addr);
     else

Thanks

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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.

So it seems to be fickle because not all the times you modprobe the 
intel module it worked.

regards

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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 */
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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.

When module loads successfully I can see in dmesg

HDA Intel 0000:05:00.0: PCI INT A -> GSI 38 (level, low) -> IRQ 38
hda_intel: probe_mask set to 0x2 for device 1102:0018
hda-intel: Invalid position buffer, using LPIB read method instead.

or:

HDA Intel 0000:05:00.0: PCI INT A -> GSI 38 (level, low) -> IRQ 38
hda_intel: probe_mask set to 0x2 for device 1102:0018
hda-intel: spurious response 0x0:0x0, last cmd=0x000000
hda-intel: Invalid position buffer, using LPIB read method instead.


And when the module doesn't load properly

HDA Intel 0000:05:00.0: PCI INT A -> GSI 38 (level, low) -> IRQ 38
hda_intel: probe_mask set to 0x2 for device 1102:0018
hda-intel: spurious response 0x0:0x0, last cmd=0x000000
hda-intel: azx_get_response timeout, switching to polling mode: last 
cmd=0x107f0d00
hda_intel: azx_get_response timeout, switching to single_cmd mode: last 
cmd=0x107f0d00
__ratelimit: 28 callbacks suppressed


Thanks,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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?


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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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?
>
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>   
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?

regards,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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?
> >
> >
> > Takashi
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@alsa-project.org
> > http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> >   
> 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?


thanks,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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

regards,

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

Re: Issue with creative Xfi PCIe ca0110-IBG

[Takashi Iwai]

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@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issue with creative Xfi PCIe ca0110-IBG

[Guillem Solà]

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à
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issue with creative Xfi PCIe ca0110-IBG

[Philippe]

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