From: Alnie <memobook80@comcast.net>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org
Subject: Re: Issues w/ Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG
Date: Mon, 09 Mar 2015 08:22:34 -0700 [thread overview]
Message-ID: <54FDBABA.2080707@comcast.net> (raw)
In-Reply-To: <54FB3E0F.4060101@comcast.net>
On 03/07/2015 10:06 AM, Alnie wrote:
> On 03/07/2015 08:32 AM, Takashi Iwai wrote:
>> At Sat, 07 Mar 2015 08:28:29 -0800,
>> Alnie wrote:
>>>
>>> On 03/06/2015 11:56 PM, Takashi Iwai wrote:
>>>> At Fri, 06 Mar 2015 15:31:32 -0800,
>>>> Alnie wrote:
>>>>>
>>>>> On 03/04/2015 01:35 AM, Takashi Iwai wrote:
>>>>>> At Wed, 04 Mar 2015 01:01:32 -0800,
>>>>>> Alnie wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 03/04/2015 12:00 AM, Takashi Iwai wrote:
>>>>>>>> At Tue, 03 Mar 2015 18:12:31 -0800,
>>>>>>>> Alnie wrote:
>>>>>>>>>
>>>>>>>>>> My suggestion isn't about a compile option but that you add
>>>>>>>>>> some debug
>>>>>>>>>> printk() calls manually around some codes. We need to know
>>>>>>>>>> the value
>>>>>>>>>> written and read by azx_write*() and azx_read*() calls.
>>>>>>>>>> Especially
>>>>>>>>>> the value read in pci_azx_read*() is more interesting. You can
>>>>>>>>>> try to
>>>>>>>>>> modify sound/pci/hda/hda_intel.c and add a printk() to each
>>>>>>>>>> pci_azx_read*() function for printing the value to be returned.
>>>>>>>>>> Beware that this will likely flood many messages, so just try
>>>>>>>>>> once.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Takashi
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I can not find any reference to pci_azx_read in hda_intel.c
>>>>>>>>
>>>>>>>> You must be using a too old kernel, then. Please use the latest
>>>>>>>> kernel for debugging.
>>>>>>>>
>>>>>>>>
>>>>>>>> Takashi
>>>>>>>>
>>>>>>>
>>>>>>> Ok. I now have latest kernel.
>>>>>>>
>>>>>>> Here is a small portion...
>>>>>>>
>>>>>>> /* PCI register access. */
>>>>>>> static void pci_azx_writel(u32 value, u32 __iomem *addr)
>>>>>>> {
>>>>>>> writel(value, addr);
>>>>>>> }
>>>>>>>
>>>>>>> static u32 pci_azx_readl(u32 __iomem *addr)
>>>>>>> {
>>>>>>> return readl(addr);
>>>>>>> }
>>>>>>>
>>>>>>> Can you show me how I can properly place printk without breaking
>>>>>>> things
>>>>>>> and produce relevant messages?
>>>>>>
>>>>>> Something like:
>>>>>>
>>>>>> static u32 pci_azx_readl(u32 __iomem *addr)
>>>>>> {
>>>>>> u32 val = readl(addr);
>>>>>> pr_info("XXX readl %p %x\n", addr, val);
>>>>>> return val;
>>>>>> }
>>>>>>
>>>>>> But since there are quite lots of accesses, it might be safer to use
>>>>>> the ratelimited version. Use like the following:
>>>>>> pr_info_ratelimited("XXX readl %p %x\n", addr, val);
>>>>>>
>>>>>> Also there are variants pci_azx_readw() and _readb().
>>>>>>
>>>>>>
>>>>>> Takashi
>>>>>>
>>>>>
>>>>>
>>>>> Ok, I was only able to guess through the code for the read values. If
>>>>> you need write information too please show me how.
>>>>> here are the mods I made...
>>>>>
>>>>> /* PCI register access. */
>>>>> static void pci_azx_writel(u32 value, u32 __iomem *addr)
>>>>> {
>>>>> writel(value, addr);
>>>>> }
>>>>>
>>>>> static u32 pci_azx_readl(u32 __iomem *addr)
>>>>> {
>>>>> u32 val = readl(addr);
>>>>> pr_info_ratelimited("XXX readl %p %x\n", addr, val);
>>>>> return val;
>>>>> }
>>>>>
>>>>> static void pci_azx_writew(u16 value, u16 __iomem *addr)
>>>>> {
>>>>> writew(value, addr);
>>>>> }
>>>>>
>>>>> static u16 pci_azx_readw(u16 __iomem *addr)
>>>>> {
>>>>> u16 val = readw(addr);
>>>>> pr_info_ratelimited("XXX readw %p %x\n", addr, val);
>>>>> return val;
>>>>> }
>>>>>
>>>>> static void pci_azx_writeb(u8 value, u8 __iomem *addr)
>>>>> {
>>>>> writeb(value, addr);
>>>>> }
>>>>>
>>>>> static u8 pci_azx_readb(u8 __iomem *addr)
>>>>> {
>>>>> u8 val = readb(addr);
>>>>> pr_info_ratelimited("XXX readb %p %x\n", addr, val);
>>>>> return val;
>>>>> }
>>>>>
>>>>> and i was able to produce this...
>>>>>
>>>>> dmesg | grep -i read
>>>>> [ 0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to
>>>>> read a pcr value
>>>>> [ 0.769674] Write protecting the kernel read-only data: 12288k
>>>>> [ 1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
>>>>> enabled, doesn't support DPO or FUA
>>>>> [ 2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache:
>>>>> enabled, doesn't support DPO or FUA
>>>>> [ 2.778875] EXT4-fs (sda5): INFO: recovery required on readonly
>>>>> filesystem
>>>>> [ 2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs
>>>>> [ 4.662442] XXX readw ffffc90004f30000 4401
>>>>
>>>> This reads good, but I thought you have two sound devices (onboard and
>>>> Creative)? If so, disable the onboard one via enable=0 option (if the
>>>> onboard one is assigned first). Otherwise the all good and bad
>>>> results are mixed up.
>>>>
>>>>
>>>> Takashi
>>>>
>>>
>>> I included options snd-hda-intel enable=0 index=0
>>>
>>> This is dmesg output (1b is onboard)...
>>> dmesg | grep -i hda
>>> [ 3.700213] snd_hda_intel: probe of 0000:00:1b.0 failed with error -2
>>> [ 37.729507] snd_hda_intel 0000:06:00.0: enabling device (0000 ->
>>> 0002)
>>> [ 37.729703] snd_hda_intel 0000:06:00.0: enabling bus mastering
>>> [ 37.736026] snd_hda_intel 0000:06:00.0: CORB reset timeout#1,
>>> CORBRP = 0
>>> [ 38.740090] snd_hda_intel 0000:06:00.0: Codec #1 probe error;
>>> disabling it...
>>> [ 38.747292] snd_hda_intel 0000:06:00.0: CORB reset timeout#1,
>>> CORBRP = 0
>>> [ 43.776089] snd_hda_intel 0000:06:00.0: no AFG or MFG node found
>>> [ 43.776111] snd_hda_intel 0000:06:00.0: no codecs initialized
>>>
>>> dmesg | grep -i XXX
>>> [ 37.729723] XXX readw ffffc90005188000 3300
>>> [ 37.729768] XXX readl ffffc90005188008 0
>>
>> OK, so all read look fine. Right now we saw a bug report with git
>> bisection showing a bad commit in HD-audio controller code. This
>> might be your issue, too. Could you try the following oneliner?
>>
>>
>> thanks,
>>
>> Takashi
>>
>> diff --git a/sound/pci/hda/hda_controller.c
>> b/sound/pci/hda/hda_controller.c
>> index 7b4377265b25..57c4575fac26 100644
>> --- a/sound/pci/hda/hda_controller.c
>> +++ b/sound/pci/hda/hda_controller.c
>> @@ -1194,7 +1194,7 @@ static unsigned int azx_rirb_get_response(struct
>> hda_bus *bus,
>> }
>> }
>>
>> - if (!bus->no_response_fallback)
>> + if (bus->no_response_fallback)
>> return -1;
>>
>> if (!chip->polling_mode && chip->poll_count < 2) {
>>
>
>
> I believe I applied the patch correctly... if you would like to double
> check here is the hda_controller.c file (http://pastebin.com/NA7AV2n1)
>
> Same complaint comes up, after reinsert and force-reload as well...
>
> [ 419.344572] snd_hda_intel 0000:06:00.0: enabling bus mastering
> [ 419.350967] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0
> [ 422.360107] snd_hda_intel 0000:06:00.0: azx_get_response timeout,
> switching to polling mode: last cmd=0x100f0000
> [ 423.364094] snd_hda_intel 0000:06:00.0: Codec #1 probe error;
> disabling it...
> [ 423.371128] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0
> [ 424.376098] snd_hda_intel 0000:06:00.0: azx_get_response timeout,
> switching to single_cmd mode: last cmd=0x100f0000
> [ 424.377052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found
> [ 424.377067] snd_hda_intel 0000:06:00.0: no codecs initialized
>
I'm assuming we've exhausted our options for now. It seems probable this
model card (ExpressCard/54) never worked in Linux to begin with. I
looked over the forum posts from those claiming they had it operational
(in 2.6 kernel), but it was for the PCI-E version. I greatly appreciate
your assistance with this. Thank you.
-Alnie
next prev parent reply other threads:[~2015-03-09 15:22 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 3:37 Issues w/ Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG Alnie
2015-03-03 6:10 ` Takashi Iwai
2015-03-03 7:22 ` Alnie
2015-03-03 7:48 ` Takashi Iwai
2015-03-03 9:21 ` Alnie
2015-03-03 21:51 ` Alnie
2015-03-03 21:58 ` Alnie
2015-03-03 22:07 ` Takashi Iwai
2015-03-04 2:12 ` Alnie
2015-03-04 8:00 ` Takashi Iwai
2015-03-04 9:01 ` Alnie
2015-03-04 9:35 ` Takashi Iwai
2015-03-06 22:38 ` Alnie
2015-03-06 22:50 ` Alnie
2015-03-06 23:31 ` Alnie
2015-03-07 7:56 ` Takashi Iwai
2015-03-07 16:28 ` Alnie
2015-03-07 16:32 ` Takashi Iwai
2015-03-07 18:06 ` Alnie
2015-03-09 15:22 ` Alnie [this message]
2015-03-09 16:00 ` Takashi Iwai
2015-03-12 3:59 ` Alnie
2015-03-12 6:19 ` Takashi Iwai
2015-03-13 2:41 ` Alnie
[not found] <54E10F0C.7070802@yahoo.com>
2015-02-15 21:33 ` Alnie
2015-02-16 16:05 ` Takashi Iwai
2015-02-16 19:03 ` Alnie
2015-02-16 19:52 ` Takashi Iwai
2015-02-22 20:47 ` Alnie
2015-02-22 20:55 ` Alnie
2015-02-24 15:37 ` Takashi Iwai
2015-02-24 18:14 ` Alnie
2015-02-24 19:52 ` Takashi Iwai
2015-02-24 20:10 ` Alnie
2015-02-24 20:39 ` Takashi Iwai
2015-02-24 21:30 ` Alnie
2015-02-25 4:37 ` Alnie
2015-02-25 6:28 ` Takashi Iwai
2015-02-25 6:51 ` Alnie
2015-02-25 7:06 ` Takashi Iwai
2015-02-25 7:32 ` Alnie
2015-02-25 7:48 ` Takashi Iwai
2015-02-25 8:01 ` Alnie
[not found] ` <54ED7FED.9080600@yahoo.com>
2015-02-25 8:06 ` Takashi Iwai
2015-02-25 8:21 ` Alnie
2015-02-25 8:23 ` Takashi Iwai
2015-02-25 8:30 ` Alnie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54FDBABA.2080707@comcast.net \
--to=memobook80@comcast.net \
--cc=alsa-devel@alsa-project.org \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.