Please, try more recent development ALSA driver tarbal from http://www.alsa-project.org/snapshot/ . If things are not working, try to determine which first ALSA version (1.0.18, 1.0.19, 1.0.20, 1.0.21) got broken.

Also attach output from 'alsa-info.sh --no-upload' script for working modules. It can be obtained from http://www.alsa-project.org/alsa-info.sh .

I've tried the 1.0.17 ALSA driver - and it works with that.

I've also happened to have tried 1.0.18a - and it worked with that as well

But that isn't the issue - it doesn't work with the ALSA driver that is part of the 5.3 kernel

i.e. it is not a case of the http://www.alsa-project.org/ drivers being broken - it appears to be the the sound module(s) in the RHEL 5 kernels that is broken with this card.

I've attached an alsa-info.sh output when using the ALSA driver 1.0.17 modules (i.e. the working case).

Do you also want the alsa-info.sh output when using the drivers from a 5.3 kernel?

Created attachment 369028 [details]
alsa-info.sh output when using alsa-driver 1.0.17

RHEL kernels contains newer HDA ALSA code. I'm trying to determine from your tests, which version is broken. Actually, the HDA update for RHEL 5.5 is based on very latest ALSA HDA driver - so it seems that our latest code has a regression. Please, tell me which ALSA version is broken for your hardware.

Works fine with alsa-drivers:

1.0.17
1.0.18a
1.0.19
1.0.20
1.0.21

I can't build the latest snapshot as it complains:

/tmp/alsa-driver-1.0.21.30.g5ed31.314.g6aea2/pci/hda/../../alsa-kernel/pci/hda/patch_via.c:2074: internal compiler error: in do_SUBST, at combine.c:486

I even built 1.0.14rc3 (as that is what /proc/asound/version reports on RHEL5) with a 3 line patch to add 'support' for the Teradici card - and that works OK as well ...

As far as I can tell, it is not broken in any ALSA version

However, it doesn't work with 5.3, 5.4 and your 'HDA update for 5.5' kernels.

By putting a liberal amount of printk's in the src, it fails when calling setup_fg_nodes() in snd_hda_codec_new() (in hda_codec.c)

Just before calling setup_fg_nodes(), it sets vendor_id, subsystem_id and revision_id - in this case (with the RHEL kernels) they are all set to 0 ...

Thank you for your testing. Could you try module option single_cmd=1 ? The communication with codec is broken if snd_hda_param_read() function returns zeros only.

And try also to compile kernel with CONFIG_SND_DEBUG and CONFIG_SND_DEBUG_DETECT .

Appearently, it might be something in backported things, but I wonder why other systems using this driver works well (this initialization sequence works).

With CONFIG_SND_DEBUG and CONFIG_SND_DEBUG_DETECT set:

ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:04:00.1 to 64
chipset global capabilities = 0x4301
codec_mask = 0x1
hda_codec: no AFG or MFG node found
hda-intel: no codecs initialized
ACPI: PCI interrupt for device 0000:04:00.1 disabled

and with single_cmd=1

PCI: Enabling device 0000:04:00.1 (0000 -> 0002)
ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:04:00.1 to 64
chipset global capabilities = 0x4301
codec_mask = 0x1
hda-intel: get_response timeout: IRS=0x1
hda-intel: send_cmd timeout: IRS=0x1, val=0xf0000
hda-intel: send_cmd timeout: IRS=0x1, val=0xf0001
hda-intel: send_cmd timeout: IRS=0x1, val=0xf0002
hda-intel: send_cmd timeout: IRS=0x1, val=0xf0004
hda_codec: no AFG or MFG node found
hda-intel: no codecs initialized
ACPI: PCI interrupt for device 0000:04:00.1 disabled

Could you trace codec commands?

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -723,6 +723,7 @@ static int azx_send_cmd(struct hda_bus *bus, unsigned int val)
 {
        struct azx *chip = bus->private_data;
 
+       printk("send_cmd: 0x%x\n", val);
        chip->last_cmd = val;
        if (chip->single_cmd)
                return azx_single_send_cmd(bus, val);

It might be also good to compare these values with a working version of ALSA (only first commands).

RHEL5 kernel with patch, dmesg output:

PCI: Enabling device 0000:04:00.1 (0000 -> 0002)
ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:04:00.1 to 64
chipset global capabilities = 0x4301
codec_mask = 0x1
send_cmd: 0xf0000
send_cmd: 0xf0001
send_cmd: 0xf0002
send_cmd: 0xf0004
no AFG or MFG node found
hda-intel: no codecs initialized
ACPI: PCI interrupt for device 0000:04:00.1 disabled

Using same patch with alsa-driver 1.0.17:

PCI: Enabling device 0000:04:00.1 (0000 -> 0002)
ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:04:00.1 to 64
send_cmd: 0xf0000
send_cmd: 0xf0001
send_cmd: 0xf0002
send_cmd: 0xf0004
send_cmd: 0x1f0005
send_cmd: 0x1f0004
send_cmd: 0x2f0009
send_cmd: 0x3f0009
send_cmd: 0x4f0009
send_cmd: 0x5f0009
send_cmd: 0x6f0009
send_cmd: 0x7f0009
send_cmd: 0x8f0009
send_cmd: 0x9f0009
send_cmd: 0xaf0009
send_cmd: 0xbf0009
send_cmd: 0xcf0009
send_cmd: 0xdf0009
send_cmd: 0xef0009
send_cmd: 0xff0009
send_cmd: 0x10f0009
send_cmd: 0x11f0009
send_cmd: 0x12f0009
...

Please, use single_cmd=1 for RHEL5 kernel to see which first I/O operation is broken.

With single_cmd=1:

PCI: Enabling device 0000:04:00.1 (0000 -> 0002)
ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:04:00.1 to 64
chipset global capabilities = 0x4301
codec_mask = 0x1
send_cmd: 0xf0000
hda-intel: get_response timeout: IRS=0x1
send_cmd: 0xf0000
hda-intel: send_cmd timeout: IRS=0x1, val=0xf0000
send_cmd: 0xf0001
hda-intel: send_cmd timeout: IRS=0x1, val=0xf0001
send_cmd: 0xf0002
hda-intel: send_cmd timeout: IRS=0x1, val=0xf0002
send_cmd: 0xf0004
hda-intel: send_cmd timeout: IRS=0x1, val=0xf0004
hda_codec: no AFG or MFG node found
hda-intel: no codecs initialized
ACPI: PCI interrupt for device 0000:04:00.1 disabled

As a test, I've rebuilt a RHEL5.3 (2.6.18-128.1.14.el5) kernel without any sound/audio patches since and including Patch22681:

linux-2.6-sound-alsa-hda-driver-update-from-upstream-2008-06-11.patch

I had to add in a 3 line patch to support the Teradici card.

With this setup, the card works:

ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:04:00.1 to 64
codec_mask = 0x1
hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...

/proc/asound/cards:

 0 [Teradici       ]: HDA-Intel - HDA Teradici
                      HDA Teradici at 0xfbbf8000 irq 177

So, I guess the problem is in Patch22681 - or one of the other subsequent sound/audio patches ...

Same kernel, but this time with Patch22681, fails ...

PCI: Setting latency timer of device 0000:04:00.1 to 64
chipset global capabilities = 0x4301
codec_mask = 0x1
hda_codec: no AFG or MFG node found
hda-intel: no codecs initialized
ACPI: PCI interrupt for device 0000:04:00.1 disabled

So the problem is in the linux-2.6-sound-alsa-hda-driver-update-from-upstream-2008-06-11.patch

(In reply to comment #11)
> With single_cmd=1:
> 
> PCI: Enabling device 0000:04:00.1 (0000 -> 0002)
> ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
> PCI: Setting latency timer of device 0000:04:00.1 to 64
> chipset global capabilities = 0x4301
> codec_mask = 0x1
> send_cmd: 0xf0000
> hda-intel: get_response timeout: IRS=0x1

OK, the first codec command fails.

(In reply to comment #13)

> So the problem is in the
> linux-2.6-sound-alsa-hda-driver-update-from-upstream-2008-06-11.patch  

I know. It's backport of ALSA code from 2008-06-11 having 25900 lines. We need only determine which lines are bad ;-(

Please, post output from this patch (rhel 5.5. kernel with hda-55-update patch), single_cmd=1):

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1214,6 +1214,7 @@ static int probe_codec(struct azx *chip, int addr)
        chip->probing = 1;
        azx_send_cmd(chip->bus, cmd);
        res = azx_get_response(chip->bus);
+       printk("probe_codec: addr=%i, res=%i\n", addr, res);
        chip->probing = 0;
        if (res == -1)
                return -EIO;
@@ -1265,6 +1266,8 @@ static int __devinit azx_codec_create(struct azx *chip, co
        if (!max_slots)
                max_slots = AZX_MAX_CODECS;
 
+       printk("axz_codec_create 1\n");
+
        /* First try to probe all given codec slots */
        for (c = 0; c < max_slots; c++) {
                if ((chip->codec_mask & (1 << c)) & chip->codec_probe_mask) {

Using a 2.6.18-171.el5 kernel with the hda-55-update patch:

With single_cmd=1

PCI: Enabling device 0000:04:00.1 (0000 -> 0002)
ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:04:00.1 to 64
axz_codec_create 1
probe_codec: addr=0, res=-1
hda-intel: Codec #0 probe error; disabling it...
hda-intel: no codecs initialized
ACPI: PCI interrupt for device 0000:04:00.1 disabled

Without single_cmd set:

ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:04:00.1 to 64
axz_codec_create 1
probe_codec: addr=0, res=0
hda-intel: no codecs initialized
ACPI: PCI interrupt for device 0000:04:00.1 disabled

One thing I have noticed, when using 'single_cmd=1' with alsa-driver 1.0.17 (and 1.0.21), then I get the same 'hda-intel: no codecs initialized' error.

Don't know if this is expected behaviour or not.

The single_cmd should work for all hardware. It looks like a timing issue.

Could you add 'mdelay(10);' to start in probe_codec() routine before mutex_lock() and report results?

Using the 2.6.18-171.el5 kernel with the mdelay(10) and single_cmd=1

PCI: Enabling device 0000:04:00.1 (0000 -> 0002)
ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:04:00.1 to 64
axz_codec_create 1
probe_codec: addr=0, res=-1
hda-intel: Codec #0 probe error; disabling it...
hda-intel: no codecs initialized
ACPI: PCI interrupt for device 0000:04:00.1 disabled

So no change here ...

Do you have any other suggestions as to what the problem might be?

Are there any other tweaks to the code that I can try?

Thanks

You may also try to set 'chip->bus->needs_damn_long_delay = 1;' in azx_codec_create() .

Also, try to load driver with and without 'single_cmd=1'.

No change - exactly the same as before ...

Created attachment 370033 [details]
Debug patch - print all I/Os

Please, apply patch from comment#22 to both RHEL5.5 and a working version of ALSA (might need some backport changes). Attach outputs for RHEL5.5 and working version of ALSA. Do not use single_cmd.

Created attachment 370059 [details]
Dmesg output using patch from comment#22 with RHEL5.5 kernel

Created attachment 370060 [details]
Dmesg output using patch from comment#22 with alsa-driver 1.0.21

Interestingly, using this patch with the alsa-driver 1.0.21, it also fails to initialize the codec ...

If I patch hda_intel.c from 1.0.21 with just the line:

printk("addr = 0x%lx, remap_addr = %p\n", chip->addr, chip->remap_addr);

then it loads OK and prints:

addr = 0xfbbf8000, remap_addr = ffffc20000030000

This is different from the RHEL5.5 kernel case where it prints:

addr = 0xfbbf8000, remap_addr = ffffc20000038000

remap_addr might change - it's virtual address.

It seems that support for Teradici controller is broken (it's really sensitive to I/O timing).

Could you try to change #define AZX_MAX_CODECS from 4 to 1 ?

Changing AZX_MAX_CODECS from 4 to 1 doesn't help (when not using the debug patch). Also, azx_max_codec[AZX_DRIVER_TERA] is already set to 1

I noticed the debug patch doesn't actually do any writes to the chip - I assume this was on purpose?

I've added the write[lwb]'s to the debug case and have the dmesg output if required.

Created attachment 370091 [details]
Debug patch - print all I/Os #2

Oops. The missing writes are ommited by mistake. Please, attach all outputs again. Thanks.

There is also a typo in the patch - the printk in azx_readb_() prints "readw" - should be "readb" - I'll change this and re-generate the outputs

Created attachment 370102 [details]
Dmesg output using patch from comment#29 with RHEL5.5 kernel

Created attachment 370104 [details]
Dmesg output using patch from comment#29 with alsa-driver 1.0.21

Created attachment 370118 [details]
Debug patch - print all I/Os #3

Created attachment 370120 [details]
Debug patch - print all I/Os #4

Please, rerun with patch in comment#35.

These diffs looks suspicious (upper 32-bits):

-writel: [ffffc20000030070]=0x3a43a000
-writel: [ffffc20000030074]=0x3
+writel: [ffffc20000030070]=0x37fe2000
+writel: [ffffc20000030074]=0x0

How much memory is in system?

You may also try to add line bellow before comment /* allow 64bit DMA address if supported by H/W */:

gcap &= ~ICH6_GCAP_64OK;

Machine has 12Gb

Adding 'gcap &= ~ICH6_GCAP_64OK' appears to make things work ...

I now get:

# cat /proc/asound/cards
 0 [Teradici       ]: HDA-Intel - HDA Teradici
                      HDA Teradici at 0xfbbf8000 irq 194

Do you still need me to rerun with the patch in comment#35 ?

As a test I removed the 'gcap &= ~ICH6_GCAP_64OK' line and booted with 'mem=3G' and the codec is found OK ...

Bingo. I only need to verify why failures are visible only under patches for RH kernels.

Could you leave only this portion of patch for vanilla 1.0.21 ALSA and test if upper 32-bits of address are not zero (and if things works in this case)?

        memset(chip->rirb.cmds, 0, sizeof(chip->rirb.cmds));
+       printk("rirb setup: 0x%lx\n", (unsigned long)chip->rirb.addr);
        azx_writel(chip, RIRBLBASE, (u32)chip->rirb.addr);

It might be necessary to load/unload modules many times.

Rebooting with the 1.0.21 ALSA driver gives:

ACPI: PCI Interrupt 0000:04:00.1[A] -> GSI 16 (level, low) -> IRQ 177
PCI: Setting latency timer of device 0000:04:00.1 to 64
rirb setup: 0x37fe1800
hda_codec: ALC888: BIOS auto-probing.

i.e. codec is found

OK, but it is not a case when rirb setup >= 0x100000000 (above 32-bit value). You may use 'rmmod snd-hda-intel; sleep 1; insmod snd-hda-intel' commands to reinsert modules (use fuser /dev/snd/* to determine which applications grabs audio devices and kill them if rmmod does not work). Also, machine should run some tasks using intensively memory (to increase the chance that the allocation will be above 4GB).

I've tried _many_ times (thousands!) rmmod'ing and insmod'ing in a loop while running a memory grabbing app - and I can not get that address above 4Gb

Having a look at the code, chip->rb is allocated memory by snd_dma_alloc_pages() which in the RHEL code calls dma_alloc_coherent() but the 1.0.21 code calls snd_dma_hack_alloc_coherent() - which appears to, in this case, sets the dev->coherent_dma_mask and dev->dma_mask to 0xffffffff before calling dma_alloc_coherent()

I can confirm this by hacking snd_dma_hack_alloc_coherent() and forcing it to do the code:

 /* reallocate with the proper mask */
  dma_free_coherent(dev, size, ret, *dma_handle);
  ret = dma_alloc_coherent(dev, size, dma_handle, flags);

and then I get:

rirb setup: 0x33c0e5800
ALSA hda_intel.c:1409: no codecs initialized

i.e., I now get an address over 4Gb and it fails to find the codec ...

You are right. The first allocation in snd_dma_hack_alloc_coherent() always succeed for you and is forced to be in 32-bit range.

So, the conclusion is that this hardware does not work with the 64-bit physical address for RIRB. The backport of snd_dma_hack_alloc_coherent() code does not make any sense for this case, because if allocation fails in first 4GB of memory, the codec communication will be broken (although this situation would be difficult to reproduce).

I'll send this patch for RHEL 5.5 kernel and for ALSA upstream:

diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 58deaee..0541b7c 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -2436,6 +2436,11 @@ static int __devinit azx_create(struct snd_card *card, struct pci_dev *pci,
                }
        }
 
+       /* disable 64bit DMA address for Teradici */
+       /* it does not work with device 6549:1200 subsys e4a2:040b */
+       if (chip->driver_type == AZX_DRIVER_TERA)
+               gcap &= ~ICH6_GCAP_64OK;
+
        /* allow 64bit DMA address if supported by H/W */
        if ((gcap & ICH6_GCAP_64OK) && !pci_set_dma_mask(pci, DMA_BIT_MASK(64)))
                pci_set_consistent_dma_mask(pci, DMA_BIT_MASK(64));

Thank you for your co-operation.

Thanks for your time on this - I'm going to report this issue to Teradici, but the patch will fix the problem for now

Teradici have got back to me stating that their device does not support 64bit DMA addresses - and provided an almost identical patch.

I guess I should have asked them first :-)

Marking as duplicate of parent bug#525390 . Please, re-open this bug in case of
any related issues with future RHEL 5.5 kernels.

*** This bug has been marked as a duplicate of bug 525390 ***

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

@moving-picture

We need to confirm that there is commitment to test for 
the resolution of this request during the RHEL 5.5 Beta 
Test Phase before we can approve it for acceptance 
into the release.

RHEL 5.5 Beta Test Phase is expected to begin around February
2010.

In order to avoid any unnecessary delays, please post a 
confirmation as soon as possible, including the contact 
information for testing engineers.

Any additional information about alternative testing variations we 
could use to reproduce this issue in-house would be appreciated.

I'm not sure what extra testing is required - the patch in Comment #44 fixes the issue - this is identical to a patch subsequently supplied by the manufacturer of the sound card and this patch is now in the upstream ALSA code

I can certainly test the 5.5 beta kernels when they come out - but I suspect they will work fine in this case

Thanks James. Your confirmation that things work as expected will be greatly appreciated.

I can confirm that all works as expected with the 2.6.18-186.el5 kernel

This issue is fixed and will be included in the 5.5 GA release. If there are any issues discovered while testing, please let us know here.