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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox