Bug 509526 - (RHEL 5.4 Alpha/Beta x86 ) no audio output on IbexPeak chipset
(RHEL 5.4 Alpha/Beta x86 ) no audio output on IbexPeak chipset
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.4
i386 Linux
high Severity high
: rc
: 5.4
Assigned To: John Feeney
Red Hat Kernel QE team
:
: 507277 510324 (view as bug list)
Depends On:
Blocks: 499437 504196 515530
  Show dependency treegraph
 
Reported: 2009-07-03 06:01 EDT by DongpoLiu
Modified: 2010-11-30 15:53 EST (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 515530 (view as bug list)
Environment:
Last Closed: 2009-09-02 04:25:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
codec#2 for RHEL Beta x86 OS from Lynnfield CPU (221 bytes, text/plain)
2009-07-06 22:16 EDT, DongpoLiu
no flags Details
codec#3 for RHEL Beta x86 OS from Lynnfield CPU (222 bytes, text/plain)
2009-07-06 22:17 EDT, DongpoLiu
no flags Details
dmesg of RHEL_5.4_Beta x86 OS from Lynnfiled CPU (31.34 KB, text/plain)
2009-07-06 22:19 EDT, DongpoLiu
no flags Details
lspci-x86_RHEL_5.4_Beta from Lynnfield CPU (4.31 KB, text/plain)
2009-07-06 22:47 EDT, DongpoLiu
no flags Details
codec#3 for RHEL Beta x86_64 OS from Lynnfield CPU (2.24 KB, text/plain)
2009-07-06 22:47 EDT, DongpoLiu
no flags Details
codec#2 for RHEL Beta x86_64 OS from Lynnfield CPU (11.13 KB, text/plain)
2009-07-06 22:48 EDT, DongpoLiu
no flags Details
dmesg_x86_64_RHEL_5.4_Beta from Lynnfield CPU (29.47 KB, text/plain)
2009-07-06 22:49 EDT, DongpoLiu
no flags Details
lspci-x86_64_RHEL_5.4_Beta from Lynnfield CPU (4.35 KB, text/plain)
2009-07-06 22:49 EDT, DongpoLiu
no flags Details
Sosreport from Clarkdale-equipped Piketon (2.26 MB, application/x-bzip)
2009-07-08 11:45 EDT, Gary Case
no flags Details
file created by alsa-info.sh on Piketon system. (31.84 KB, text/plain)
2009-07-08 14:28 EDT, John Feeney
no flags Details
dmesg from Lynnfield with 2.6.18-157.el5jfeeney509526.1 x86 kernel (32.57 KB, text/plain)
2009-07-08 23:05 EDT, DongpoLiu
no flags Details
set 3stack-6ch-intel model for IbexPeak (570 bytes, patch)
2009-07-11 06:05 EDT, Wu Fengguang
no flags Details | Diff
dmesg from Lynnfield with 2.6.18-157.el5jfeeney509526.1 x86 kernel, RHEL Snap1 OS (31.11 KB, text/plain)
2009-07-13 03:42 EDT, DongpoLiu
no flags Details
dmesg from Lynnfield with 2.6.18-157.el5jfeeney509526.1 x86 kernel, RHEL Snap1 OS (bdl_pos_adj=32) (31.11 KB, text/plain)
2009-07-13 21:40 EDT, DongpoLiu
no flags Details
alsa-info output for x86_64 updated (C0) system that does not have sound. (29.20 KB, text/plain)
2009-07-14 18:37 EDT, John Feeney
no flags Details
alsa-info.sh output from RHEL 5.3 i386 on IbexPeak B1 with Clarkdale C0 proc (26.36 KB, text/plain)
2009-07-15 10:51 EDT, John Villalovos
no flags Details
3stack-6ch-intel-ibx model for IbexPeak (1.90 KB, patch)
2009-07-17 08:46 EDT, Wu Fengguang
no flags Details | Diff
alsa-info.sh txt when rhel5.4 has AZX_MAX_CODECS set to 3. (27.64 KB, application/octet-stream)
2009-07-17 16:38 EDT, John Feeney
no flags Details
IbexPeak audio patch for RHEL 5.4 (9.61 KB, patch)
2009-07-21 09:25 EDT, Wu Fengguang
no flags Details | Diff
IbexPeak audio patch for RHEL 5.4 (11.74 KB, patch)
2009-07-22 11:22 EDT, Wu Fengguang
no flags Details | Diff
IbexPeak audio patch for upstream 2.6.30 (11.45 KB, patch)
2009-07-22 11:23 EDT, Wu Fengguang
no flags Details | Diff
IbexPeak audio patch for sound-2.6 git tree (11.33 KB, patch)
2009-07-22 11:25 EDT, Wu Fengguang
no flags Details | Diff
IbexPeak related patches fixing wrong codec verb access (3.64 KB, patch)
2009-07-22 12:31 EDT, Jaroslav Kysela
no flags Details | Diff
Complete patch for inclusion to RHEL 5.4 kernel (17.54 KB, patch)
2009-07-22 13:05 EDT, Jaroslav Kysela
no flags Details | Diff
add more ids for HDMI and ALC889A codecs (1.52 KB, patch)
2009-07-22 23:46 EDT, Wu Fengguang
no flags Details | Diff
add 2-channel mode to the Intel 889/889A models (3.11 KB, patch)
2009-07-23 09:40 EDT, Wu Fengguang
no flags Details | Diff
fix ALSA compile error when CONFIG_SND_DEBUG=y (885 bytes, patch)
2009-07-23 22:09 EDT, Wu Fengguang
no flags Details | Diff
Isolate codec command/response so that the Realtek audio won't be messed up by the broken HDMI codec (6.30 KB, patch)
2009-08-03 03:13 EDT, Wu Fengguang
no flags Details | Diff

  None (edit)
Description DongpoLiu 2009-07-03 06:01:20 EDT
I installed RHEL 5.4 Alpha/Beta i386 into Lynnfield:

Detail is as follows:
[root@osve-lp ~]# aplay  /usr/share/sounds/email.wav 
ALSA lib pcm_direct.c:866:(snd1_pcm_direct_initialize_slave) snd_pcm_hw_params_any failed
ALSA lib pcm_dmix.c:1020:(snd_pcm_dmix_open) unable to initialize slave
aplay: main:583: audio open error: Invalid argument

[root@osve-lp ~]# lsmod | grep snd 
snd_hda_intel         423953  1 
snd_seq_dummy           7877  0 
snd_seq_oss            32577  0 
snd_seq_midi_event     11073  1 snd_seq_oss
snd_seq                49585  5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device         11725  3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss            42817  0 
snd_mixer_oss          19009  1 snd_pcm_oss
snd_pcm                72133  2 snd_hda_intel,snd_pcm_oss
snd_timer              24517  2 snd_seq,snd_pcm
snd_page_alloc         14281  2 snd_hda_intel,snd_pcm
snd_hwdep              12869  1 snd_hda_intel
snd                    55749  11 snd_hda_intel,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_hwdep
soundcore              11553  1 snd

[root@osve-lp ~]# uname -a
Linux osve-lp.sh.intel.com 2.6.18-155.el5 #1 SMP Fri Jun 19 17:06:47 EDT 2009 i686 i686 i386 GNU/Linux

in dmesg, we can see 
[root@osve-lp ~]# dmesg | grep Unknown
hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...


while we can hear voice at RHEL 5.4 Alpha/Beta x86_64 OS.
Comment 1 John Feeney 2009-07-06 14:54:29 EDT
First, I don't see any apparent reason why this would work on x86_64 and fail on i386. Most ALSA changes are independent of processor specific compilations, but I guess something is amiss.

Second, would it be possible to get the outpuf of 'cat /proc/asound/card0/codec*'?

Third, I assume you don't see the "Unknown model" message in dmesg when running RHEL5.4 x86_64. Is that true?

Fourth, does this fail in a similar way with a recent upstream kernel?
Comment 2 DongpoLiu 2009-07-06 22:16:48 EDT
Created attachment 350714 [details]
codec#2 for RHEL Beta x86 OS from Lynnfield CPU
Comment 3 DongpoLiu 2009-07-06 22:17:38 EDT
Created attachment 350715 [details]
codec#3 for RHEL Beta x86 OS from Lynnfield CPU
Comment 4 DongpoLiu 2009-07-06 22:19:09 EDT
Created attachment 350716 [details]
dmesg of RHEL_5.4_Beta x86 OS from Lynnfiled CPU
Comment 5 DongpoLiu 2009-07-06 22:46:24 EDT
(In reply to comment #1)
> First, I don't see any apparent reason why this would work on x86_64 and fail
> on i386. Most ALSA changes are independent of processor specific compilations,
> but I guess something is amiss.
> Second, would it be possible to get the outpuf of 'cat
> /proc/asound/card0/codec*'?
see as attachement.
> Third, I assume you don't see the "Unknown model" message in dmesg when running
> RHEL5.4 x86_64. Is that true?
we can see same 3 Unknown model at x86_64 OS.
> Fourth, does this fail in a similar way with a recent upstream kernel?  
I will try with latest linux-2.6.30.1 kernel, stay tune.....
Comment 6 DongpoLiu 2009-07-06 22:47:15 EDT
Created attachment 350720 [details]
lspci-x86_RHEL_5.4_Beta from Lynnfield CPU
Comment 7 DongpoLiu 2009-07-06 22:47:50 EDT
Created attachment 350721 [details]
codec#3 for RHEL Beta x86_64 OS from Lynnfield CPU
Comment 8 DongpoLiu 2009-07-06 22:48:21 EDT
Created attachment 350722 [details]
codec#2 for RHEL Beta x86_64 OS from Lynnfield CPU
Comment 9 DongpoLiu 2009-07-06 22:49:25 EDT
Created attachment 350723 [details]
dmesg_x86_64_RHEL_5.4_Beta from Lynnfield CPU
Comment 10 DongpoLiu 2009-07-06 22:49:56 EDT
Created attachment 350724 [details]
lspci-x86_64_RHEL_5.4_Beta from Lynnfield CPU
Comment 11 DongpoLiu 2009-07-06 22:52:01 EDT
some Info from Intel side: Fengguang, Wu is as follows:
> - lspci is same
> - dmesg is different, there are many warnings in 32bit kernel(the last three lines):
> 
>           hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...
>           input: HDA Digital PCBeep as /class/input/input3
>         + hda_intel: azx_get_response timeout, switching to polling mode: last cmd=0x70af000b
>         + hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x70af000b
>         + printk: 236 messages suppressed.
> 
> - codec#2 (Realtek ALC889A) is good in 64bit kernel, N/A in 32bit kernel
> - codec#3 (Intel G45 DEVIBX)is good in 64bit kernel, N/A in 32bit kernel
> 
> I guess it's not really an audio/BIOS problem, but the x86 and x86_64
> archs are doing interrupts in a slightly different way, so that x86_64
> succeeded whereas x86 is forced into the terrible single_cmd mode.

I noticed that the IO/MEM windows are different in x86/x86_64,
the x86 windows end with all 0:

  PCI: Bridge: 0000:00:03.0                                       |  PCI: Bridge: 0000:00:03.0
    IO window: e000-efff                                          |    IO window: e000-0000                                          
    MEM window: f8000000-fb0fffff                                 |    MEM window: f8000000-00000000                                 
    PREFETCH window 0x00000000e0000000-0x00000000efffffff         |    PREFETCH window 0x00000000e0000000-0x00000000efffffff

00:03.0 PCI bridge: Intel Corporation Clarksfield/Lynnfield PCI Express Root Port 1
Comment 12 Jaroslav Kysela 2009-07-07 06:49:02 EDT
It seems that this patch might solve this issue:

http://git.alsa-project.org/?p=alsa-kmirror.git;a=commitdiff;h=e2f27264744b273dc2ef90cb47fa3fab7dc28a4a;hp=cad7197d1d9fb2a1aa082c5e592b5be257553358

But the recent ALSA repository have many fixes regarding HDA bus communication problems, so more changes might be required to solve this problem.
Comment 13 John Feeney 2009-07-07 10:33:42 EDT
I will apply the patch and provide the rpms as quickly as soon as possible. (Thanks, Jaroslav)
Comment 14 Ronald Pacheco 2009-07-07 11:44:39 EDT
Note that this blocks BZ 506196, which is a requirement for RHEL 5.4, so I set the blocker flag to "?"
Comment 15 John Feeney 2009-07-07 16:48:00 EDT
The rpms with the patch provided by comment #12 can be found on my people page.
See http://people.redhat.com/jfeeney/.bz509526
Comment 16 Gary Case 2009-07-07 17:18:02 EDT
I just tried the RPMs from John's people page. They don't make a difference on my Clarkdale C0 equipped Piketon. If I run "system-config-soundcard" program, it sees the card, but nothing plays (instant "Did you hear the sound?" dialog box after pressing play).
Comment 17 DongpoLiu 2009-07-08 00:38:09 EDT
at RHEL 5.4 Beta x86 OS, tried with tried linux 2.6.30.1 kernel:
1) we can do playback/microphne record/volume control at front audio channel now
2) as to back audio channel, 
2.1) heard noise when playing 
2.2) micphone record failed,
2.3) volume control OK
Comment 18 DongpoLiu 2009-07-08 00:56:00 EDT
(In reply to comment #17)
> at RHEL 5.4 Beta x86 OS, tried with tried linux 2.6.30.1 kernel:
> 1) we can do playback/microphne record/volume control at front audio channel
> now
> 2) as to back audio channel, 
> 2.1) heard noise when playing 
this should be "heard noise when playing  song1_128kbps.ogg/song1_96kbps.ogg" 
> 2.2) micphone record failed,
> 2.3) volume control OK
Comment 19 Jaroslav Kysela 2009-07-08 04:05:47 EDT
Regarding comment#16. Could you attach output from 'dmesg' and 'alsa-info.sh --no-upload' running John's kernel? Thank you.
Comment 20 John Villalovos 2009-07-08 08:53:47 EDT
Seth,

Do you have any input on this bug?
Comment 21 Gary Case 2009-07-08 11:45:55 EDT
Created attachment 350958 [details]
Sosreport from Clarkdale-equipped Piketon

I'm uploading a sosreport from the affected Clarkdale Piketon machine. Note, this machine is x86_64 and running the jfeeney kernel.
Comment 22 Gary Case 2009-07-08 11:47:55 EDT
Regarding comment 19, where do I get the 'alsa-info.sh' script?
Comment 23 John Feeney 2009-07-08 14:27:36 EDT
An update...

1. I downloaded alsa-info.sh from http://git.alsa-project.org/?p=alsa-driver.git;a=blob_plain;f=utils/alsa-info.sh
and got a txt file when I ran it on a Piketon system. See enclosed.

2. This Piketon (Ibex Peak) system had 2.6.18-154.el5 x86_64 installed. I found that I could hear sound out the front headphones jack (aplay and/or system-config-soundcard). Still, there was a line in dmesg that indicated that azx_get_response_time() had failed and it was "switching to polling mode", along with the line about "unknown model for ALC883". Perhaps, x86_64 is on the edge so that at least polling works.

3. I checked srpm for the kernel that I built yesterday (see comment #15) to make sure the patch provided by Jaroslav was there and it was. Just making sure.
Comment 24 John Feeney 2009-07-08 14:28:50 EDT
Created attachment 350977 [details]
file created by alsa-info.sh on Piketon system.
Comment 25 DongpoLiu 2009-07-08 23:05:01 EDT
Created attachment 351012 [details]
dmesg from Lynnfield with 2.6.18-157.el5jfeeney509526.1 x86 kernel
Comment 26 John Feeney 2009-07-09 15:12:39 EDT
There seems to be a hardware upgrade issue that is making this problem appear even more complex. 

Systems where lspci reports "Intel Corporation Ibex Peak PT IDER Controller (rev 04)" (see Gary's comment (e.g. #16) also report that "hda-codec: No codec parser is available" and there is no sound even on x86_64. Also see bz510324 where the azx_get_response() times out but when the system hardware was upgraded (to C0), it got the "hda-codec: No codec parser is available" message also. 

My system has not been updated (lspci says rev 02)and so gets some time outs but does get sound on x86_64. It would appear as though the systems upon which this bugzilla was found are still rev 02 (see enclosed lspci output) so they would exhibit a different problem (seemingly less severe) than the upgraded ones.
Comment 27 DongpoLiu 2009-07-09 21:40:22 EDT
(In reply to comment #26)
> There seems to be a hardware upgrade issue that is making this problem appear
> even more complex. 
> Systems where lspci reports "Intel Corporation Ibex Peak PT IDER Controller
> (rev 04)" (see Gary's comment (e.g. #16) also report that "hda-codec: No codec
> parser is available" and there is no sound even on x86_64. 
Comments:after install RHEL 5.4 x86_64 OS into Lynnfield Platform:
1)we can get audio output from fromt panel and back panel, 
2)while we failed to do micphone recording/playing song1_128kbps.ogg/song1_96kbps.ogg.

No audio output issue only happens at Lynnfield RHEL Beta x86 OS, then we built and installed upstream 2.6.30.1 kernel into RHEL x86 OS:
1) we get audio output from fromt panel and back panel, 
2) while failed to do micphone recording/playing song1_128kbps.ogg/song1_96kbps.ogg.

> Also see bz510324,where the azx_get_response() times out but when the system > hardware was upgraded (to C0), it got the "hda-codec: No codec parser is 
> available" message also. 
> My system has not been updated (lspci says rev 02)and so gets some time outs
> but does get sound on x86_64. It would appear as though the systems upon which
> this bugzilla was found are still rev 02 (see enclosed lspci output) so they
> would exhibit a different problem (seemingly less severe) than the upgraded
> ones.
Comment 28 DongpoLiu 2009-07-09 21:49:37 EDT
(In reply to comment #15)
> The rpms with the patch provided by comment #12 can be found on my people page.
> See http://people.redhat.com/jfeeney/.bz509526  

we cannot get audio output with kernel-2.6.18-157.el5jfeeney509526.1.i686.rpm, see as follows:
[root@osve-lp ~]# uname -a
Linux osve-lp 2.6.18-157.el5jfeeney509526.1 #1 SMP Tue Jul 7 13:26:18 EDT 2009 i686 i686 i386 GNU/Linux
[root@osve-lp ~]# aplay  /usr/share/sounds/*.wav 
ALSA lib pcm_direct.c:866:(snd1_pcm_direct_initialize_slave) snd_pcm_hw_params_any failed
ALSA lib pcm_dmix.c:1020:(snd_pcm_dmix_open) unable to initialize slave
aplay: main:583: audio open error: Invalid argument
Comment 29 Jaroslav Kysela 2009-07-10 06:47:12 EDT
I think that I found the culprit of the codec communication problems:

http://git.alsa-project.org/?p=alsa-kmirror.git;a=commitdiff;h=ae889d6f764559932485be23e6ad2744164fc9d1

But this bug is in the auto-configuration parser (ALSA guesses how is I/O connected), so I would try to add this model to /etc/modprobe.conf as workaround for tests:

options snd-hda-intel index=0 model=3stack-6ch-intel

Please, report result with this model (I cannot test the audio outputs/inputs remotely). We can prepare a patch which chooses this model automatically.
Comment 30 John Feeney 2009-07-10 13:47:50 EDT
Jaroslav,
I assume you changed the modprobe.conf on the system I provided you yesterday because I see your change.

While aplay did not report errors like it did yesterday, there was no sound from the front headphone. I did get sound out of one of the rear jacks.

I run alsaunmute and changed some alsamixer values but that still had no effect.
Comment 31 John Feeney 2009-07-10 14:38:59 EDT
Okay, I installed the last patch (from comment #29), removed the modprobe.conf change, and rebooted. I now get sound from the front jack. I see in dmesg that the printk added by the patch is seen, thus there was an "invalid dig_nid connection of 0xf781 for NID 0x1c". 

I can't record just yet. 

Note: This is on the upgraded Ibex Peak with an i386 2.6.18-157.el5 kernel. 

Since it is pretty well documented that newer Ibex Peak exhibit different problems from older Ibex Peak and only the newer ones will be shipped, I do not have any data for x86_64 just yet, because my x86_64 system is being upgraded. Giving non rev C0 results at this point is fruitless.
Comment 32 John Feeney 2009-07-10 17:24:25 EDT
I built a x86_64 5.4 release with the patch as provided by comment #29. Please find it on my people page at http://people.redhat.com/jfeeney/.bz509526 specifically kernel-2.6.18-157.el5jfeeney509526.2.x86_64

The i386 version is still building.
Comment 33 Gary Case 2009-07-10 18:42:30 EDT
I'm testing the 20090708.0 x86_64 build on my Piketon Clarkdale C0 and audio playback appears to work without any modification whatsoever. I tested the front and rear audio connections individually and can hear the test sound during install on either one.
Comment 34 Gary Case 2009-07-10 19:01:05 EDT
Interestingly enough, it *doesn't* work with the 157 non-Xen kernel. My testing that succeeded was with kernel-xen. Even with the patched
kernel-2.6.18-157.el5jfeeney509526.2.x86_64 I don't get any sound. It just immediately runs to "did you hear the sample sound?".
Comment 35 Wu Fengguang 2009-07-11 06:05:38 EDT
Created attachment 351333 [details]
set 3stack-6ch-intel model for IbexPeak 

This patch automates the module params proposed by Jaroslav:
      options snd-hda-intel index=0 model=3stack-6ch-intel
Comment 36 DongpoLiu 2009-07-13 03:40:49 EDT
(In reply to comment #35)
> Created an attachment (id=351333) [details]
> set 3stack-6ch-intel model for IbexPeak 
> This patch automates the module params proposed by Jaroslav:
>       options snd-hda-intel index=0 model=3stack-6ch-intel  

I tried  2.6.18-157.el5jfeeney509526.1 i686 kernel, configure "options snd-hda-intel index=0  model=3stack-6ch-intel" in /etc/modprobe.conf.

I can 
succeeed doing playback/microphone record at front pannel 
succeeed doing playback at back panel,while fail with microphone record. 

Details:
[root@osve-lp ~]# uname -a
Linux osve-lp 2.6.18-157.el5jfeeney509526.1 #1 SMP Tue Jul 7 13:26:18 EDT 2009 i686 i686 i386 GNU/Linux
Comment 37 DongpoLiu 2009-07-13 03:42:36 EDT
Created attachment 351437 [details]
dmesg from Lynnfield with 2.6.18-157.el5jfeeney509526.1 x86 kernel, RHEL Snap1 OS
Comment 38 Wu Fengguang 2009-07-13 03:54:20 EDT
(In reply to comment #37)
> Created an attachment (id=351437) [details]
> dmesg from Lynnfield with 2.6.18-157.el5jfeeney509526.1 x86 kernel, RHEL Snap1
> OS  

It says:
          hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.

How about passing the module params "bdl_pos_adj=1" or "bdl_pos_adj=32"?
Comment 39 DongpoLiu 2009-07-13 21:38:09 EDT
with "options snd-hda-intel index=0  model=3stack-6ch-intel  bdl_pos_adj=1" in /etc/modprobe.conf, we got
1) font panel:fail with playback or micro-phone record
2) back panel:succeed with playback, while fail with micro-phone record

with "options snd-hda-intel index=0  model=3stack-6ch-intel  bdl_pos_adj=32" in /etc/modprobe.conf, we got
1) font panel:succeed with playback, while fail with micro-phone record
2) back panel:succeed with playback, while fail with micro-phone record


OS Kernel:
[root@osve-lp initial]# uname -a
Linux osve-lp 2.6.18-157.el5jfeeney509526.1 #1 SMP Tue Jul 7 13:26:18 EDT 2009 i686 i686 i386 GNU/Linux
Comment 40 DongpoLiu 2009-07-13 21:40:17 EDT
Created attachment 351543 [details]
dmesg from Lynnfield with 2.6.18-157.el5jfeeney509526.1 x86 kernel, RHEL Snap1 OS (bdl_pos_adj=32)

dmesg with bdl_pos_adj=32 options
Comment 41 John Feeney 2009-07-14 14:14:13 EDT
Okay so now we have sound playing front and back with a patch and two parameters to modprobe.conf on i386. That's good. But no recording, that's bad. 

Just to make sure we are all working with the same hardware, the Piketon version used in comments #35-40 was Piketon Clarkdale C0, right?
Comment 42 John Villalovos 2009-07-14 15:39:51 EDT
*** Bug 510324 has been marked as a duplicate of this bug. ***
Comment 43 John Feeney 2009-07-14 18:03:19 EDT
I checked x86_64 2.6.18-157.el5jfeeney509526.1 and found that I had no sound front or back with any combination of potential fixes. This was done on upgraded hardware (Piketon Clarkdale CO). I tried the following: 
  a. 2.6.18-157 with no additional patches found above and standard
      modprobe.conf
  b. 2.6.18-157 with no additional patches found above and modprobe.conf 
     "model=3stack-6ch-intel" on snd-hda-intel line
  c. 2.6.18-157 with no additional patches found above and a snd-hda-intel 
      line of options snd-hda-intel index=0  model=3stack-6ch-intel 
      bdl_pos_adj=32
  d. The patch to check for out-of-range dig_nids (comment #29) plus  
      options snd-hda-intel index=0  model=3stack-6ch-intel  bdl_pos_adj=32
  e. The patch to check for out-of-range dig_nids (comment #29) and standard
      modprobe.conf
  f. The patch to check for out-of-range dig_nids (comment #29), the patch to
      add the quirk for Ibex Peak (comment #35), and "options snd-hda-intel
      index=0 model=3stack-6ch-intel  bdl_pos_adj=32" in modprobe.conf

Since this was 2.6.18-157.el5jfeeney5095265.1, the patch provided by comment #12 present in all tests.

In each try, aplay would return errors such as "unable to initialize", system-config-soundcard would immediately return asking if I heard sound, and a "no codec parsers" message would be written to /var/log/messages during boot.

It should be noted that these findings are similar to what was reported elsewhere using x86_64 (non-xen) on the upgraded Piketon Clarksdale (C0) hardware. See comment #34 and comment #6 in bz510324. I will attach the alsa-info output file for this x86_64 system.

I then checked i386 with 2.6.18-157 and found that I could hear sound (aplay or system-config-soundcard) through either front or rear jack when the patch for out-of-range dig_nids (comment #29) was installed BUT if "model=3stack-6ch-intel" was added to modprobe.conf, I lost sound on the front jack. Again, this was done on upgraded hardware (CO).

Note: in this case aplay did not produce errors nor did system-config-soundcard return immediately but there was no sound from the front jack. 

Obviously, my i386 findings contradict the reports of sound being heard on i386 with the additional modprobe.conf parameters to snd-hda-intel.
Comment 44 John Feeney 2009-07-14 18:37:19 EDT
Created attachment 351705 [details]
alsa-info output for x86_64 updated (C0) system that does not have sound.
Comment 45 Wu Fengguang 2009-07-15 04:43:23 EDT
(In reply to comment #43)
> I checked x86_64 2.6.18-157.el5jfeeney509526.1 and found that I had no sound
> front or back with any combination of potential fixes. This was done on
> upgraded hardware (Piketon Clarkdale CO). I tried the following: 
[snip]
> "no codec parsers" message would be written to /var/log/messages during boot.

Are there any more ALSA/HDA info in the dmesg?
I found no "no codec parsers" message in the source code, which is grabbed from

http://people.redhat.com/dzickus/el5/157.el5/src/kernel-2.6.18-157.el5.src.rpm

> It should be noted that these findings are similar to what was reported
> elsewhere using x86_64 (non-xen) on the upgraded Piketon Clarksdale (C0)
> hardware. See comment #34 and comment #6 in bz510324. I will attach the
> alsa-info output file for this x86_64 system.
> 
> I then checked i386 with 2.6.18-157 and found that I could hear sound (aplay or
> system-config-soundcard) through either front or rear jack when the patch for
> out-of-range dig_nids (comment #29) was installed BUT if
> "model=3stack-6ch-intel" was added to modprobe.conf, I lost sound on the front
> jack. Again, this was done on upgraded hardware (CO).

I compared the codec#2 in (C0) and a previous one from DongpoLiu,
and noticed that although the IDs are all the same, the PINs' IN/OUT configurations vary a lot.

PIN: old x86_64 => C0 x86_64
0x17: IN => OUT  (Speaker at Ext Rear, Black)
0x19: OUT => IN  (Line Out at Ext Rear, Black)
0x1b: IN => OUT  (Mic at Ext Rear, Pink)

DongpoLiu, do you have the upgraded (C0) hardware?
Comment 46 DongpoLiu 2009-07-15 04:57:17 EDT
(In reply to comment #45)
> (In reply to comment #43)
> > I checked x86_64 2.6.18-157.el5jfeeney509526.1 and found that I had no sound
> > front or back with any combination of potential fixes. This was done on
> > upgraded hardware (Piketon Clarkdale CO). I tried the following: 
> [snip]
> > "no codec parsers" message would be written to /var/log/messages during boot.
> Are there any more ALSA/HDA info in the dmesg?
> I found no "no codec parsers" message in the source code, which is grabbed from
> http://people.redhat.com/dzickus/el5/157.el5/src/kernel-2.6.18-157.el5.src.rpm
> > It should be noted that these findings are similar to what was reported
> > elsewhere using x86_64 (non-xen) on the upgraded Piketon Clarksdale (C0)
> > hardware. See comment #34 and comment #6 in bz510324. I will attach the
> > alsa-info output file for this x86_64 system.
> > 
> > I then checked i386 with 2.6.18-157 and found that I could hear sound (aplay or
> > system-config-soundcard) through either front or rear jack when the patch for
> > out-of-range dig_nids (comment #29) was installed BUT if
> > "model=3stack-6ch-intel" was added to modprobe.conf, I lost sound on the front
> > jack. Again, this was done on upgraded hardware (CO).
> I compared the codec#2 in (C0) and a previous one from DongpoLiu,
> and noticed that although the IDs are all the same, the PINs' IN/OUT
> configurations vary a lot.
> PIN: old x86_64 => C0 x86_64
> 0x17: IN => OUT  (Speaker at Ext Rear, Black)
> 0x19: OUT => IN  (Line Out at Ext Rear, Black)
> 0x1b: IN => OUT  (Mic at Ext Rear, Pink)
> DongpoLiu, do you have the upgraded (C0) hardware?  
our platform comes with Ibex Peak A1/Lynnfield A0, and I failed in updating BIOS today and am waiting for help from BIOS team.

To upgrade to C0 platform, I will check with team.
Comment 47 John Villalovos 2009-07-15 10:26:17 EDT
I just tested RHEL 5.3 x86_64 on the new IbexPeak motherboard with Clarkdale C0 processor.

Using aplay I was able to hear audio output on both the front and rear output.

So this seems to be a regression in that RHEL 5.3 works but we are having issues with RHEL 5.4.

I did this in text mode because RHEL 5.3 has a bug regarding video support for the Clarkdale / IronLake processor.
Comment 48 John Villalovos 2009-07-15 10:46:33 EDT
Tested RHEL 5.3 i386 on the new IbexPeak motherboard with Clarkdale C0
processor.

Using aplay I was able to hear audio output on both the front and rear output.

On both RHEL 5.3 architectures I booted the non-Xen (aka baremetal) kernel for testing.
Comment 49 John Villalovos 2009-07-15 10:51:39 EDT
Created attachment 353834 [details]
alsa-info.sh output from RHEL 5.3 i386 on IbexPeak B1 with Clarkdale C0 proc

This is the alsa-info.sh output from the working RHEL 5.3 i386 system.  This system has the upgraded IbexPeak motherboard with Clarkdale C0 processor.
Comment 50 John Villalovos 2009-07-15 17:11:23 EDT
Comment from Intel Premier support who tested it on Windows:

------------------------
I just confirmed on an IbexPeak B1 chipset motherboard (revision E35324-304) the Microphone does work.  I had to adjust the audio properties to include microphone boost in order to hear the recording.  The default audio was extremely low and my headset was low quality.
------------------------

My upgraded IbexPeak B1 / Clarkdale C0 has the exact same motherboard revision as listed by Premier.

So microphone completely not working is most likely not a hardware issue.
Comment 51 John Feeney 2009-07-15 18:38:39 EDT
There are four patches in RHEL5.4 that deal with ALSA, three small ones and one giant one (around 22,000 lines). I removed all four patches from a 5.4 kernel on x86_64 with updated hardware and heard sounds through the front and rear headphone jacks. I restored the giant patch (linux-2.6-alsa-hda-update-for-rhel-5-4.patch) and there was no sound to be heard through either jack. system-config-soundcard immediately asked if I heard sound. (Gee, I would imagine everyone is shocked as me that the giant patch was the culprit as opposed to making it easy on us if one of the smaller ones was causing trouble.)

As opposed to yesterday when I guessed at the error log message verbiage (since I had seen it many times and it was already reported a number of times above), the error message found when booting with this giant patch is

Jul 15 14:26:36 intel-piketon-tpm-03 kernel: Too many connections
Jul 15 14:26:36 intel-piketon-tpm-03 kernel: hda-codec: No codec parser is available

I find the "No codec parser" line to be found in hda_codec.c line 996 when snd_hda_parse_generic_codec() fails. Or
        /* call the default parser */
        err = snd_hda_parse_generic_codec(codec);
        if (err < 0)
                printk(KERN_ERR "hda-codec: No codec parser is available\n");

I apologize for not providing the correct information previously (comment #44).
Comment 52 John Feeney 2009-07-16 18:10:51 EDT
Today's findings:

I found that RHEL5.4 calls snd_hda_codec_new() 2 times from azx_codec_create() while 5.3 only calls it once. The second call to snd_hda_codec_new() fails, for example in build_afg_tree(). So why does 5.4 call it twice? The loop that does the calling is as follows:
 
       /* Then create codec instances */
        for (c = 0; c < max_slots; c++) {
                if ((chip->codec_mask & (1 << c)) & chip->codec_probe_mask) {
                        struct hda_codec *codec;
                        err = snd_hda_codec_new(chip->bus, c, !no_init, &codec);                                    
                        if (err < 0)
                                continue;
                        codecs++;
                }
        }

The value of chip->codec_mask is 0xc and chip->codec_probe_mask is 0xffffffff so the if statement would be true twice with a value of 0xc (1100). But what about max_slots which is initialized with the AZX_MAX_CODECS #define. In 5.4 AZX_MAX_CODECS is 4 BUT in 5.3 it is assigned a value of 3. A three would prevent the second call to snd_hda_codec_new(). So, I changed the value of AZX_MAX_CODECS on my 5.4 code base to 3, recompiled, and heard sound after booting. 

I am not saying the proper fix is to restore AZX_MAX_CODECS to 3, but I am pointing out that when two calls are made to snd_hda_codec_new(), you get no sound output and setting AZX_MAX_CODECS to 3 prevents the extra call. 

Note: upstream code has AZX_MAX_CODECS assigned a value of 4.
Comment 53 Chaohong Guo 2009-07-16 23:01:56 EDT
I don't completely understand why ALSA needs to set a limit for codec address (max_slots). But I guess it is some hardware wrongly report code_masks after hardware resetting.

From the output of RH5.3 attached in comments 49, seems that RH5.3 found only one HDA codecs. I don't have any hardware to verify this. But I guess that Ironlake should have an additional HDMI codec of Intel,  except RealTek ALC885 (10ec0885).

From the comment 51, seems that RH5.4 don't put the vendor/device Id of the HDMI codec into snd_hda_preset_intelhdmi[] of the file patch_intelhdmi.c,  as a result, generic topology parser is called to handle it. I don't have HDMI codec manual, but I guess it is NOT HDA spec compatible one, or ALSA generic parser is not good enough, for whatever reason, the parser failed.

However, even if failed to init HDMI codec,  the RLC885 should work. There must be other bugs.
Comment 54 Wu Fengguang 2009-07-16 23:48:36 EDT
(In reply to comment #53)
> I don't completely understand why ALSA needs to set a limit for codec address
> (max_slots). But I guess it is some hardware wrongly report code_masks after
> hardware resetting.

John mentioned in #52 that codec_mask=0xc, which is correct for DongpoLiu's hardware(): there is codec#2=ALC889 and codec#3=Intel HDMI. John's alsa-info
didn't show the HDMI codec. Why are the two IbexPeak hardwares so different?
Johh, maybe the HDMI codec is there but disabled in BIOS?

John enabled the sound by hacking AZX_MAX_CODECS to 3. I guess another equivalence would be to pass in the module param "probe_mask=4".

> From the output of RH5.3 attached in comments 49, seems that RH5.3 found only
> one HDA codecs. I don't have any hardware to verify this. But I guess that
> Ironlake should have an additional HDMI codec of Intel,  except RealTek ALC885
> (10ec0885).
> 
> From the comment 51, seems that RH5.4 don't put the vendor/device Id of the
> HDMI codec into snd_hda_preset_intelhdmi[] of the file patch_intelhdmi.c,  as a
> result, generic topology parser is called to handle it. I don't have HDMI codec

It's not a HDMI driver problem. I can find the ID in RHEL kernel source:

linux-2.6-alsa-hda-update-for-rhel-5-4.patch:+  { .id = 0x80862804, .name = "G45 DEVIBX", .patch = patch_intel_hdmi },

> manual, but I guess it is NOT HDA spec compatible one, or ALSA generic parser
> is not good enough, for whatever reason, the parser failed.

Our HDMI codec is confirming to HDA.

> However, even if failed to init HDMI codec,  the RLC885 should work. There must
> be other bugs.
Comment 55 Wu Fengguang 2009-07-17 00:26:39 EDT
(In reply to comment #52)
> Today's findings:
> 
> I found that RHEL5.4 calls snd_hda_codec_new() 2 times from azx_codec_create()
> while 5.3 only calls it once. The second call to snd_hda_codec_new() fails, for
> example in build_afg_tree().

A tip on debugging ALSA:

It helps a lot to enable the CONFIG_SND_DEBUG_VERBOSE and CONFIG_SND_HDA_HWDEP/CONFIG_SND_HDA_RECONFIG kconfigs.

The former would make it much easier to disclose sound problems in dmesg(like this one); the latter ones would allow runtime reconfiguration of the codecs.
Comment 56 Chaohong Guo 2009-07-17 01:38:56 EDT
(In reply to comment #54)
> (In reply to comment #53)
> > I don't completely understand why ALSA needs to set a limit for codec address
> > (max_slots). But I guess it is some hardware wrongly report code_masks after
> > hardware resetting.
> 
> John mentioned in #52 that codec_mask=0xc, which is correct for DongpoLiu's
> hardware(): there is codec#2=ALC889 and codec#3=Intel HDMI. John's alsa-info
> didn't show the HDMI codec. Why are the two IbexPeak hardwares so different?
> Johh, maybe the HDMI codec is there but disabled in BIOS?
> 
> John enabled the sound by hacking AZX_MAX_CODECS to 3. I guess another
> equivalence would be to pass in the module param "probe_mask=4".

Yes.  probe_mask=4 kernel parameter should achieve the same goal. According to
spec, there should be 15 codecs at most. But alsa limits it to 4. I was just
wondering why ALSA needs to do that.

From comment 52, John changed AZX_MAX_CODECS to 3, and it works. In doing so,
ALSA won't init CODEC 3 (intel HDMI), and just init'ed Realtek codec. If just
such a small change can enable realtek88x to work,  it is weird.

For John, can you post codec info in /proc and dmesg with the AZX_MAX_CODECS =
3 kernel.


From comment 4, the dmesg has the following :

   hda_intel: azx_get_response timeout, switching to polling mode: last
     cmd=0x70af000b
   hda_intel: azx_get_response timeout, switching to single_cmd mode: last 
      cmd=0x70af000b
   printk: 236 messages suppressed.

According to codec info attached to comment 2 & 3, the system has codec#2 &
codec#3,  why the last_cmd is 0x70af000b, which indicates somebody is trying to
read supported format from codec#7 ????
Comment 57 Wu Fengguang 2009-07-17 02:25:18 EDT
(In reply to comment #56)
> (In reply to comment #54)
> > (In reply to comment #53)
> > > I don't completely understand why ALSA needs to set a limit for codec address
> > > (max_slots). But I guess it is some hardware wrongly report code_masks after
> > > hardware resetting.
> > 
> > John mentioned in #52 that codec_mask=0xc, which is correct for DongpoLiu's
> > hardware(): there is codec#2=ALC889 and codec#3=Intel HDMI. John's alsa-info
> > didn't show the HDMI codec. Why are the two IbexPeak hardwares so different?
> > Johh, maybe the HDMI codec is there but disabled in BIOS?
> > 
> > John enabled the sound by hacking AZX_MAX_CODECS to 3. I guess another
> > equivalence would be to pass in the module param "probe_mask=4".
> 
> Yes.  probe_mask=4 kernel parameter should achieve the same goal. According to
> spec, there should be 15 codecs at most. But alsa limits it to 4. I was just
> wondering why ALSA needs to do that.
> 
> From comment 52, John changed AZX_MAX_CODECS to 3, and it works. In doing so,
> ALSA won't init CODEC 3 (intel HDMI), and just init'ed Realtek codec. If just
> such a small change can enable realtek88x to work,  it is weird.

It could cause problem if trying to probe non-existence codec.

> From comment 4, the dmesg has the following :
> 
>    hda_intel: azx_get_response timeout, switching to polling mode: last
>      cmd=0x70af000b
>    hda_intel: azx_get_response timeout, switching to single_cmd mode: last 
>       cmd=0x70af000b
>    printk: 236 messages suppressed.
> 
> According to codec info attached to comment 2 & 3, the system has codec#2 &
> codec#3,  why the last_cmd is 0x70af000b, which indicates somebody is trying to
> read supported format from codec#7 ????  

See #29, that should be caused by BIOS/ALSA bugs during auto-config.
Comment 58 Chaohong Guo 2009-07-17 03:04:25 EDT
> > 
> > From comment 52, John changed AZX_MAX_CODECS to 3, and it works. In doing so,
> > ALSA won't init CODEC 3 (intel HDMI), and just init'ed Realtek codec. If just
> > such a small change can enable realtek88x to work,  it is weird.
> 
> It could cause problem if trying to probe non-existence codec.
> 
> > From comment 4, the dmesg has the following :
> > 
> >    hda_intel: azx_get_response timeout, switching to polling mode: last
> >      cmd=0x70af000b
> >    hda_intel: azx_get_response timeout, switching to single_cmd mode: last 
> >       cmd=0x70af000b
> >    printk: 236 messages suppressed.
> > 
> > According to codec info attached to comment 2 & 3, the system has codec#2 &
> > codec#3,  why the last_cmd is 0x70af000b, which indicates somebody is trying to
> > read supported format from codec#7 ????  
> 
> See #29, that should be caused by BIOS/ALSA bugs during auto-config.  

No, I doubt that. BIOS reports the same value regardless 32-bit or 64-bit OS, however,  64bit rh5.4 works while 32bit RH5.4 doesn't. Besides, I think the commit ae889d6f764559932485be23e6ad2744164fc9d1 has some confusion:

According to the comments with that commit,  snd_hda_get_connections() returns a valid connection (0xffff or f8f9), however, according to HDA spec, 0x7fff is the max widget ID, the routine snd_hda_get_connections() should NOT return that invalid connection at all.
Comment 59 Wu Fengguang 2009-07-17 08:46:56 EDT
Created attachment 354135 [details]
3stack-6ch-intel-ibx model for IbexPeak 

Regarding the MIC/record problem, this is a patch based on wild guess.
Could someone try it out? Thanks.
Comment 60 John Feeney 2009-07-17 16:37:00 EDT
Thanks for all the info.

1. I tried 3stack-6ch-intel-ibx patch from comment #59 and that did not work. dmesg messages are as follows:
  hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...
  input: HDA Digital PCBeep as /class/input/input3
  ALSA sound/pci/hda/hda_codec.c:346: Too many connections
  hda-codec: No codec parser is available

2. CONFIG_SND_DEBUG_VERBOSE is not found in RHEL5 but I do see it in 2.6.30. I enabled SND_VERBOSE_PRINTK but it didn't seem as though it added much.

3. I changed AZX_MAX_CODECS in RHEL5.3 to 4 and got the same error messages after compiling and rebooting: "Invalid AFG subtree" and "hda_codec: No codec parser is available". It looks like this hardware just happened to work on RHEL5.3. 

4. For those wondering how AZX_MAX_CODECS became 4, see commit 
43f14e2201e249e08bdef07fa0845d6709b568a6 with the following comment:

   Allow probing of 4 codecs on known good situations.
 
   On some known bad situations, it should be avoided.


5. For those wondering about bios, I did not see anything that would indictate it controlled codecs. The bios version is American Megatrends core version 4.6.3.2, if that helps. 

6. With RHEL5.4 and AZX_MAX_CODECS changed to 3, I got the following dmesg output:
 Jul 17 13:30:27 intel-piketon-tpm-03 kernel: hda_codec: Unknown model for  ALC883, trying auto-probe from BIOS...
 Jul 17 13:30:27 intel-piketon-tpm-03 kernel: input: HDA Digital PCBeep as /class/input/input3

I enclosed the alsa-info.txt file too.
Comment 61 John Feeney 2009-07-17 16:38:19 EDT
Created attachment 354205 [details]
alsa-info.sh txt when rhel5.4 has AZX_MAX_CODECS set to 3.
Comment 62 Wu Fengguang 2009-07-17 22:55:35 EDT
(In reply to comment #60)
> Thanks for all the info.
> 
> 1. I tried 3stack-6ch-intel-ibx patch from comment #59 and that did not work.
> dmesg messages are as follows:
>   hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...
>   input: HDA Digital PCBeep as /class/input/input3
>   ALSA sound/pci/hda/hda_codec.c:346: Too many connections
>   hda-codec: No codec parser is available

Hmm, what if you specify "model=3stack-6ch-intel-ibx" explicitly?

> 2. CONFIG_SND_DEBUG_VERBOSE is not found in RHEL5 but I do see it in 2.6.30. I
> enabled SND_VERBOSE_PRINTK but it didn't seem as though it added much.

Sorry, seems that RHEL5 is still using the old name CONFIG_SND_DEBUG_DETECT.
(more exactly, the two names are all used in fact. will submit a patch for
 converting to the new name for the sake of consistency.)

> 3. I changed AZX_MAX_CODECS in RHEL5.3 to 4 and got the same error messages
> after compiling and rebooting: "Invalid AFG subtree" and "hda_codec: No codec
> parser is available". It looks like this hardware just happened to work on
> RHEL5.3. 
> 
> 4. For those wondering how AZX_MAX_CODECS became 4, see commit 
> 43f14e2201e249e08bdef07fa0845d6709b568a6 with the following comment:
> 
>    Allow probing of 4 codecs on known good situations.
> 
>    On some known bad situations, it should be avoided.
> 
> 
> 5. For those wondering about bios, I did not see anything that would indictate
> it controlled codecs. The bios version is American Megatrends core version
> 4.6.3.2, if that helps. 

Not exactly the name codecs, but I have saw "HDMI" enable/disable options in recent boards.

> 6. With RHEL5.4 and AZX_MAX_CODECS changed to 3, I got the following dmesg
> output:
>  Jul 17 13:30:27 intel-piketon-tpm-03 kernel: hda_codec: Unknown model for 
> ALC883, trying auto-probe from BIOS...
>  Jul 17 13:30:27 intel-piketon-tpm-03 kernel: input: HDA Digital PCBeep as
> /class/input/input3
> 
> I enclosed the alsa-info.txt file too.  

Thanks!
Comment 63 Jaroslav Kysela 2009-07-18 06:06:13 EDT
It looks like a hw/BIOS problem: The NID CONNLIST_LEN verb for NID#8 for codec#3 (HDMI) returns too big value thus the routine snd_hda_get_connections() is confused. This commit is a workaround for this issue:

http://git.alsa-project.org/?p=alsa-kmirror.git;a=commitdiff;h=93fd148a2250de218a5e3642cb41329132dd01fe

Regarding capture issues:

I would recomend to try hda-analyzer and play with input widget settings to find what should be controlled from the ALSA side:

wget -O run.py http://www.alsa-project.org/hda-analyzer.py
python run.py
Comment 64 Wu Fengguang 2009-07-20 01:48:52 EDT
(In reply to comment #63)
> It looks like a hw/BIOS problem: The NID CONNLIST_LEN verb for NID#8 for
> codec#3 (HDMI) returns too big value thus the routine snd_hda_get_connections()
> is confused. This commit is a workaround for this issue:
> 
> http://git.alsa-project.org/?p=alsa-kmirror.git;a=commitdiff;h=93fd148a2250de218a5e3642cb41329132dd01fe

Just a feedback: I got this output after applying the above patch:

[   17.255448] alc880_auto: invalid dig_nid connection 0xffff for NID 0x1c

I just installed the latest sound-2.6 git on IbexPeak B1.
Comment 65 John Villalovos 2009-07-20 13:46:35 EDT
Jaroslav,

I ran the hda-analyzer.py on my system:
----output----
[root@intel-piketon-02 ~]#  python run.py  
Creating temporary directory: /dev/shm/hda-analyzer
Downloading file hda_analyzer.py
Downloading file hda_codec.py
Downloaded all files, executing hda_analyzer.py
No HDA codecs were found or insufficient priviledges for 
/dev/snd/controlC* and /dev/snd/hwdepC*D* device files.

You may also check, if you compiled HDA driver with HWDEP
interface as well or close all application using HWDEP.

Try run this program as root user.
-----end output----

This was on a RHEL 5.3 kernel:
2.6.18-128.el5 #1 SMP Wed Dec 17 11:42:39 EST 2008 i686 i686 i386 GNU/Linux
Comment 66 John Feeney 2009-07-20 17:50:59 EDT
Back to sound output...

I tried the patch provided in comment #63 and I got the printk in dmesg so yes there would appear to be a hardware issue with the HDMI codec whereby the CONNECT_LEN verb returns too big a value BUT sound is still not heard. aplay fails with a series of errors and system-config-soundcard returns immediately with the did-you-hear-something question. I did this with x86_64 RHEL5.4 on new hardware.

I am not sure why the "invalid dig_nid connection" error occurred as described in comment #64 with Ibex Peak B1. I didn't get that error.

The output from aplay is as follows:
aplay /usr/share/sounds/*.wav
ALSA lib pcm_direct.c:866:(snd1_pcm_direct_initialize_slave) snd_pcm_hw_params_any failed
ALSA lib pcm_dmix.c:1020:(snd_pcm_dmix_open) unable to initialize slave
aplay: main:583: audio open error: Invalid argument
[root@intel-piketon-tpm-03 card0]#
Comment 67 Ronald Pacheco 2009-07-20 18:18:05 EDT
John Hull,

Can you please post your test results to this BZ?  It is unclear if we are seeing an issue with the SDPs we have in-house (BIOS) or a real bug.  OEM test results will help tremendously!

Thanks and Regards,

Ron
Comment 68 Jaroslav Kysela 2009-07-21 04:06:02 EDT
(In reply to comment #65)
> Jaroslav,
> 
> I ran the hda-analyzer.py on my system:
> ----output----
> [root@intel-piketon-02 ~]#  python run.py  
> Creating temporary directory: /dev/shm/hda-analyzer
> Downloading file hda_analyzer.py
> Downloading file hda_codec.py
> Downloaded all files, executing hda_analyzer.py
> No HDA codecs were found or insufficient priviledges for 
> /dev/snd/controlC* and /dev/snd/hwdepC*D* device files.
> 
> You may also check, if you compiled HDA driver with HWDEP
> interface as well or close all application using HWDEP.
> 
> Try run this program as root user.
> -----end output----
> 
> This was on a RHEL 5.3 kernel:
> 2.6.18-128.el5 #1 SMP Wed Dec 17 11:42:39 EST 2008 i686 i686 i386 GNU/Linux  

This analyzer will not work with the RHEL 5.3 kernel. HWDEP interface is not enabled for older kernels.
Comment 69 Jaroslav Kysela 2009-07-21 04:09:25 EDT
(In reply to comment #66)
> Back to sound output...
> 
> I tried the patch provided in comment #63 and I got the printk in dmesg so yes
> there would appear to be a hardware issue with the HDMI codec whereby the
> CONNECT_LEN verb returns too big a value BUT sound is still not heard. aplay
> fails with a series of errors and system-config-soundcard returns immediately
> with the did-you-hear-something question. I did this with x86_64 RHEL5.4 on new
> hardware.
> 
> I am not sure why the "invalid dig_nid connection" error occurred as described
> in comment #64 with Ibex Peak B1. I didn't get that error.
> 
> The output from aplay is as follows:
> aplay /usr/share/sounds/*.wav
> ALSA lib pcm_direct.c:866:(snd1_pcm_direct_initialize_slave)
> snd_pcm_hw_params_any failed
> ALSA lib pcm_dmix.c:1020:(snd_pcm_dmix_open) unable to initialize slave
> aplay: main:583: audio open error: Invalid argument
> [root@intel-piketon-tpm-03 card0]#  

I think you made wrong changes to code:

        /* Then create codec instances */
        for (; c < azx_max_codecs[chip->driver_type]; c++) {

should be:

       /* Then create codec instances */
        for (c = 0; c < azx_max_codecs[chip->driver_type]; c++) {

You skipped codec#2 (main codec) initialization and only HDMI codec was used (thus no PCM interface was created).

I fixed this issue on intel-piketon-tpm-03 machine.
Comment 70 Wu Fengguang 2009-07-21 04:47:47 EDT
Some good news:

I can now enter the 3stack-6ch-intel-ibx model and enable front/back MIC inputs
by the following HDA verbs:

hda-verb /dev/snd/hwC0D2 0x24 SET_AMP_GAIN_MUTE 0x7000
hda-verb /dev/snd/hwC0D2 0x24 SET_AMP_GAIN_MUTE 0x7200
hda-verb /dev/snd/hwC0D2 0x24 SET_AMP_GAIN_MUTE 0x7300
hda-verb /dev/snd/hwC0D2 0x1b SET_PIN_WIDGET_CONTROL 0x24

I also have a patch for automating this, but I'm not sure this is the optimal
solution. Just want to share the progress: we are seeing the hope :)
Comment 71 Wu Fengguang 2009-07-21 09:25:05 EDT
Created attachment 354482 [details]
IbexPeak audio patch for RHEL 5.4

I lucklily got an IbexPeak B1/Clarkdale C0 hardware that should be the same one with John Feeney. With extensive experiments in the latest sound-2.6 git kernel, I'm able to produce this patch that is expected to resolve this bug.

This patch is for RHEL 5.4, but the tests were carried out in its upstream version. (Sorry it's too late, I'm only able to do the backporting for today.)

tested features:
- Front Headphone: OK
- Front Mic/Rear Mic recording: OK
- 8 channel output: Front/Rear/CLFE/Side all OK

not tested yet:
- digital input/output (I have no equipments for this test)
- concurrent intputs to 2 MICs (shall we need this?)

design issues:
- input_mux is absent: I have no idea what it is (seems to work with the
  coefficient index of node 0x20, which is black magic to me).
- alc889_init_input_verbs: This makes FRONT-MIC/LINE-IN recordable, by
  summing signals from FRONT-MIC/REAR-MIC/LINE-INs to node 0x24 => 0x07.
  This may be a hack, are there better options?

The patch needs more public reviews, but I'd like to post it here for early testing/feedback in RHEL. Thank you.
Comment 72 John Feeney 2009-07-21 15:27:48 EDT
Jaroslav,

As for your comment about the for statement being wrong (comment #69), I believe you caught me in the middle of my attempt to back out the patch that changed AZX_MAX_CODECS from 3 to 4 and that is why 
        /* Then create codec instances */
        for (; c < azx_max_codecs[chip->driver_type]; c++) {
was the way it was when you found it. See commit 2f5983f2aaffbc92addc4ec378989a1c200cf3dd 


As for your patches (comments 12, 29, 63), I built a kernel with all three (see /usr/src/kernels/2.6.18-157 on intel-piketon-tpm-03) and I still don't get sound. Aplay fails. I see where the two error messages are displayed in dmesg so yes, I am hitting the last two patches.

hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...
alc880_auto: invalid dig_nid connection 0xffff for NID 0x1c
input: HDA Digital PCBeep as /class/input/input3
ALSA sound/pci/hda/hda_codec.c:330: hda_codec: invalid CONNECT_LIST verb 8[0]:0


Could it be possible that your hardware is not the most recent? I would ask you to please test your patches on intel-piketon-tpm-03 because Intel assures me that it is has all the most current updates. As I have stated before, you don't need to hear at this point, aplay's failure is quite apparent.

[root@intel-piketon-tpm-03 hda]# aplay
ALSA lib pcm_direct.c:866:(snd1_pcm_direct_initialize_slave) snd_pcm_hw_params_any failed
ALSA lib pcm_dmix.c:1020:(snd_pcm_dmix_open) unable to initialize slave
aplay: main:583: audio open error: Invalid argument
Comment 73 John Villalovos 2009-07-21 16:27:17 EDT
(In reply to comment #71)
> Created an attachment (id=354482) [details]
> IbexPeak audio patch for RHEL 5.4
> 
> The patch needs more public reviews, but I'd like to post it here for early
> testing/feedback in RHEL. Thank you.  

I tested the patch and on my -158 kernel it crashes and get a kernel panic :(

I am trying to get it setup on a system where I can capture the serial port output so that I can get the complete crash dump.
Comment 74 Wu Fengguang 2009-07-21 20:50:06 EDT
(In reply to comment #73)

> I tested the patch and on my -158 kernel it crashes and get a kernel panic :(

I'm now ready to run a RHEL kernel. Where can I download the same kernel source you are using? Thanks.
Comment 75 John Villalovos 2009-07-21 21:00:59 EDT
(In reply to comment #74)
> (In reply to comment #73)
> 
> > I tested the patch and on my -158 kernel it crashes and get a kernel panic :(
> 
> I'm now ready to run a RHEL kernel. Where can I download the same kernel source
> you are using? Thanks.  

http://people.redhat.com/dzickus/el5/

Also if you have questions regarding Red Hat, Luming Yu at Intel, is a remote on-site partner engineer at Red Hat.  So he can help you if it is after hours for me.
Comment 76 Jaroslav Kysela 2009-07-22 08:46:27 EDT
(In reply to comment #72)
> Could it be possible that your hardware is not the most recent? I would ask you
> to please test your patches on intel-piketon-tpm-03 because Intel assures me
> that it is has all the most current updates. As I have stated before, you don't
> need to hear at this point, aplay's failure is quite apparent.
> 
> [root@intel-piketon-tpm-03 hda]# aplay
> ALSA lib pcm_direct.c:866:(snd1_pcm_direct_initialize_slave)
> snd_pcm_hw_params_any failed
> ALSA lib pcm_dmix.c:1020:(snd_pcm_dmix_open) unable to initialize slave
> aplay: main:583: audio open error: Invalid argument  

I figured that accessing codec#3 confuses the HDA bus communication and wrong data are read sometimes thus PCM format mask is initialized with wrong values (hw_params fails then). Disabling HDMI codec (probe_mask=4 as module option) helps.

I created this patch to skip reading connections for widget with an unknown type. It seems that it fixes this problem.

http://git.alsa-project.org/?p=alsa-kmirror.git;a=commitdiff;h=e9bcc0ca2a4550b0eabbf48504e105d163cfc7d2
Comment 77 Wu Fengguang 2009-07-22 09:19:23 EDT
(In reply to comment #76)

> I figured that accessing codec#3 confuses the HDA bus communication and wrong
> data are read sometimes thus PCM format mask is initialized with wrong values
> (hw_params fails then). Disabling HDMI codec (probe_mask=4 as module option)
> helps.
> 
> I created this patch to skip reading connections for widget with an unknown
> type. It seems that it fixes this problem.
> 
> http://git.alsa-project.org/?p=alsa-kmirror.git;a=commitdiff;h=e9bcc0ca2a4550b0eabbf48504e105d163cfc7d2  

I didn't notice the codec#3 problem because I disabled HDMI codec and BIOS reports correct codec mask 0x4. But anyway this looks like a good improvement.

Regarding the patch, snd_hda_get_connections() is called in a dozen places,
how about moving the sanity checks into that function? And will this be better to use "if (wid_caps & AC_WCAP_CONN_LIST)" ?

I'll try this patch after enabling HDMI codec tomorrow. Thanks.
Comment 78 Jaroslav Kysela 2009-07-22 09:38:23 EDT
(In reply to comment #77)
> (In reply to comment #76)
> 
> > I figured that accessing codec#3 confuses the HDA bus communication and wrong
> > data are read sometimes thus PCM format mask is initialized with wrong values
> > (hw_params fails then). Disabling HDMI codec (probe_mask=4 as module option)
> > helps.
> > 
> > I created this patch to skip reading connections for widget with an unknown
> > type. It seems that it fixes this problem.
> > 
> > http://git.alsa-project.org/?p=alsa-kmirror.git;a=commitdiff;h=e9bcc0ca2a4550b0eabbf48504e105d163cfc7d2  
> 
> I didn't notice the codec#3 problem because I disabled HDMI codec and BIOS
> reports correct codec mask 0x4. But anyway this looks like a good improvement.
> 
> Regarding the patch, snd_hda_get_connections() is called in a dozen places,
> how about moving the sanity checks into that function? And will this be better
> to use "if (wid_caps & AC_WCAP_CONN_LIST)" ?

Thanks for this note. The fixed condition is in:

http://git.alsa-project.org/?p=alsa-kmirror.git;a=commitdiff;h=e9bcc0ca2a4550b0eabbf48504e105d163cfc7d2
Comment 80 Wu Fengguang 2009-07-22 11:22:36 EDT
Created attachment 354713 [details]
IbexPeak audio patch for RHEL 5.4
Comment 81 Wu Fengguang 2009-07-22 11:23:42 EDT
Created attachment 354714 [details]
IbexPeak audio patch for upstream 2.6.30
Comment 82 Wu Fengguang 2009-07-22 11:25:02 EDT
Created attachment 354715 [details]
IbexPeak audio patch for sound-2.6 git tree
Comment 83 RHEL Product and Program Management 2009-07-22 11:34:10 EDT
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.
Comment 84 John Villalovos 2009-07-22 11:43:43 EDT
(In reply to comment #80)
> Created an attachment (id=354713) [details]
> IbexPeak audio patch for RHEL 5.4  

This patch does not crash the system and I can hear audio out of the front and rear panels.
Comment 85 Wu Fengguang 2009-07-22 11:45:52 EDT
    Here are the new sound enabling patches for IbexPeak.
    It addresses the two design issues in the previous version.

    It's developed and tested in the sound-2.6 git tree.
    The RHEL5.4 and 2.6.30 backports are mostly identical.

    Summary of my (re)tests:

    - playback
      - Front Headphone: OK
      - 8 channel audio: Front/Rear/CLFE/Side all OK

    - recording
      - Front Mic/Rear Mic: both OK
        (front/rear/line mics are selectable in the "Input source" alsamixer
    control)
      - Line In: not working
        (in 6ch mode, its amp/mute, direction and route all looks fine,
         so I'm a little puzzled)
        (hopefully no one will care this feature)

    - digital SPDIF input/output: not tested (no equipment)
Comment 86 Jaroslav Kysela 2009-07-22 11:48:24 EDT
Wu, these lines in rhel patch look suspicious:

+	SND_PCI_QUIRK(0x8086, 0x0022, "DX58SO", ALC889_INTEL),
+	SND_PCI_QUIRK(0x8086, 0x3b56, "Intel IbexPeak", ALC885_INTEL),

Should not be ALCXXX identifiers switched?
Comment 87 Wu Fengguang 2009-07-22 11:52:37 EDT
(In reply to comment #84)
> (In reply to comment #80)
> > Created an attachment (id=354713) [details] [details]
> > IbexPeak audio patch for RHEL 5.4  
> 
> This patch does not crash the system and I can hear audio out of the front and
> rear panels.  

Wow great, that's really good news.(In reply to comment #86)

> Wu, these lines in rhel patch look suspicious:
> 
> + SND_PCI_QUIRK(0x8086, 0x0022, "DX58SO", ALC889_INTEL),
> + SND_PCI_QUIRK(0x8086, 0x3b56, "Intel IbexPeak", ALC885_INTEL),
> 
> Should not be ALCXXX identifiers switched?  

What do you mean Jaroslav? "Intel IbexPeak" is not good name but currently we
don't know the board name yet. The ALC889_INTEL/ALC885_INTEL names are based
on the codec ids. What would you suggest? You know I'm a bit clueless on choosing good names :)
Comment 88 Wu Fengguang 2009-07-22 12:10:30 EDT
(In reply to comment #84)
> (In reply to comment #80)
> > Created an attachment (id=354713) [details] [details]
> > IbexPeak audio patch for RHEL 5.4  
> 
> This patch does not crash the system and I can hear audio out of the front and
> rear panels.  

Here is my testing procedures.

- recording

1.1) in alsamixer, select "front mic" in "Input source",
1.2) then test the front mic with command "arecord -d5 hi.wav; aplay hi.wav";

2.1) in alsamixer, select "mic" in "Input source",
2.2) then test the rear mic with same command in 1.2

Note that arecord also supports --channel, but I have not tried that.
And for good record quality, the volumes for the capture sources shall be set to low values (< 30).

- playback

1) make sure in alsamixer the channel mode is set to 8 channels.
2) run "speaker-test -c8 -twav -D surround71" and check outputs of the rear ports

Thanks.
Comment 89 Wu Fengguang 2009-07-22 12:12:38 EDT
(In reply to comment #88)
> 
> Note that arecord also supports --channel, but I have not tried that.

arecord --channels or -c, sorry for the mistake.
Comment 90 Jaroslav Kysela 2009-07-22 12:13:26 EDT
> > Wu, these lines in rhel patch look suspicious:
> > 
> > + SND_PCI_QUIRK(0x8086, 0x0022, "DX58SO", ALC889_INTEL),
> > + SND_PCI_QUIRK(0x8086, 0x3b56, "Intel IbexPeak", ALC885_INTEL),
> > 
> > Should not be ALCXXX identifiers switched?  
> 
> What do you mean Jaroslav? "Intel IbexPeak" is not good name but currently we
> don't know the board name yet. The ALC889_INTEL/ALC885_INTEL names are based
> on the codec ids. What would you suggest? You know I'm a bit clueless on
> choosing good names :)  

According to the chip revision, it should be ALC889A.
Comment 91 Wu Fengguang 2009-07-22 12:18:44 EDT
(In reply to comment #90)

> According to the chip revision, it should be ALC889A.  

Right, I'll fix the name to ALC889A_INTEL in the next update.
Comment 92 Jaroslav Kysela 2009-07-22 12:31:02 EDT
Created attachment 354732 [details]
IbexPeak related patches fixing wrong codec verb access

With this patch basic I/O is available using auto-config code.

Tested:

Real Panel:
===========
Left/Right output
Surround Left/Right output
Center/LFE output
Mic input

Front Panel:
============
Left/Right output
Mic input (fails sometimes)
Comment 93 Jaroslav Kysela 2009-07-22 12:34:48 EDT
(In reply to comment #92)
> Created an attachment (id=354732) [details]
> IbexPeak related patches fixing wrong codec verb access

Note this patch must be applied when HDMI codec #3 is enabled in system (otherwise main ALC889A codec initialization might fail sometimes).
Comment 94 John Feeney 2009-07-22 12:57:24 EDT
I installed just the patch introduced by comment #85 on my system and I still don't get sound (without adding probe_mask to /etc/modprobe.conf). 

aplay fails as miserably as seen previously.

[root@intel-piketon-tpm-03 ~]# aplay /usr/share/sounds/*.wav
ALSA lib pcm_direct.c:866:(snd1_pcm_direct_initialize_slave) snd_pcm_hw_params_any failedALSA lib pcm_dmix.c:1020:(snd_pcm_dmix_open) unable to initialize slave
aplay: main:583: audio open error: Invalid argument

John Villalovos installed the kernel that successfully played sound on his system on my system and aplay failed again. 

This is an x86_64 Lynnfield system as opposed to a Clarkdale that John has. Since there don't seem to be any bios options, we can only conclude that the problem lies in the fact that it is Lynnfield.
Comment 95 Jaroslav Kysela 2009-07-22 13:01:25 EDT
(In reply to comment #94)
> I installed just the patch introduced by comment #85 on my system and I still
> don't get sound (without adding probe_mask to /etc/modprobe.conf). 
> 
> aplay fails as miserably as seen previously.

John, please, could you also apply my patch from comment#92? On systems with HDMI codec enabled, patch from comment#85 might fail.
Comment 96 John Villalovos 2009-07-22 13:04:44 EDT
(In reply to comment #94)
> This is an x86_64 Lynnfield system as opposed to a Clarkdale that John has.
> Since there don't seem to be any bios options, we can only conclude that the
> problem lies in the fact that it is Lynnfield.  

For those who don't know the difference.

Clarkdale is a processor with a built in graphics unit.  When using a Clarkdale processor you can use the video output connectors on the motherboard.

Lynnfield is another processor which can be used in an Ibex Peak chipset motherboard.  Lynnfield does NOT have a built in graphics unit.  So you must use a separate video card.

So the Clarkdale may have an HDMI audio output that if using a Lynnfield you would not see.
Comment 97 Jaroslav Kysela 2009-07-22 13:05:11 EDT
Created attachment 354741 [details]
Complete patch for inclusion to RHEL 5.4 kernel

This patch is combination of patch#354732 and patch#354713 with minor modification - renaming ALC885 identifiers to ALC889A.

After tests I'm going to send these patches to rhkernel and take patch#354715 (with ALC885->ALC889A change) to mainstream.
Comment 99 John Villalovos 2009-07-22 15:06:00 EDT
Testing of patch from Comment 97 works on both the Clarkdale and Lynnfield IbexPeak systems.
Comment 101 John Feeney 2009-07-22 15:50:19 EDT
Record works with rear jack on Lynnfield along with sound output front and rear
with patch from comment #97.

Thanks to all.
   John
Comment 103 Wu Fengguang 2009-07-22 23:46:33 EDT
Created attachment 354812 [details]
add more ids for HDMI and ALC889A codecs

Jaroslav, please also push this patch to rhkernel.

- Add ID for the Intel HDMI codec#3
- Add ID for the ALC889A codec#2
  (this 0x80860021 id is reported by the codec but not yet pci,
   just in case the pci id will be changed to that id in future)
Comment 104 Wu Fengguang 2009-07-23 09:40:43 EDT
Created attachment 354856 [details]
add 2-channel mode to the Intel 889/889A models

Add 2-channel mode, which will broadcast the 2-channel audio to every other output jacks. Note that in 6/8-channel mode, 2-channel music tracks will be
only available in the green line out jack, other output jacks will remain silent.
Comment 105 Wu Fengguang 2009-07-23 09:59:35 EDT
I compiled an 32bit RHEL kernel from kernel-2.6.18-159.el5.src.rpm.
It runs OK on IbexPeak with CONFIG_SND_DEBUG=y.
- front/rear output jacks all can produce sound
- front/rear mics all records fine
- 2/6/8-channel audios all plays well

But the testing was not smooth.

- the vmlinuz-2.6.18-157.el5PAE kernel that comes with the fresh installation
  dies hard for two times, then I upgraded to kernel vmlinuz-2.6.18-159.el5
  and it works fine.
- then I downloaded kernel-2.6.18-159.el5.src.rpm, applied patches (id=354741)
  (id=354812) and (id=354856). The audio input/output seems not working, and
  it reports:
        hda_intel: azx_get_response timeout, switching to polling mode:
                   last cmd=0x20df0012
  So I recompiled kernel to include options
        CONFIG_SND_DEBUG=y
        CONFIG_SND_DEBUG_DETECT=y
  which gets rid of the dmesg warning.
  Also I have to use the commands (note the "plughw" device; "hw" wont work)
        speaker-test -c2 -twav -D plughw:0,0
        speaker-test -c8 -twav -D plughw:0,0
        arecord -D plughw:0,0 -d5 hi.wav; aplay -D plughw:0,0 hi.wav
  to get rid of such errors:
        Channels count (8) not available for playbacks: Invalid argument
        Setting of hwparams failed: Invalid argument
  or
        arecord: set_params:954: Sample format non available
Comment 108 Jaroslav Kysela 2009-07-23 12:10:26 EDT
(In reply to comment #105)
> - then I downloaded kernel-2.6.18-159.el5.src.rpm, applied patches (id=354741)
>   (id=354812) and (id=354856). The audio input/output seems not working, and

It seems that two later patches (id=354812 and 354856) causes some problems (no audio output on our development systems - patch 354741 is OK). I would suggest to not merge these patches to rhel kernel until we figure what's wrong.
Comment 109 John Villalovos 2009-07-23 15:02:54 EDT
(In reply to comment #105)
> I compiled an 32bit RHEL kernel from kernel-2.6.18-159.el5.src.rpm.
> It runs OK on IbexPeak with CONFIG_SND_DEBUG=y.

When I enable CONFIG_SND_DEBUG=y I get an error during make:

sound/pci/hda/hda_codec.c: In function ‘snd_hda_get_connections’:
sound/pci/hda/hda_codec.c:279: error: implicit declaration of function ‘WARN’
make[3]: *** [sound/pci/hda/hda_codec.o] Error 1
make[2]: *** [sound/pci/hda] Error 2
make[1]: *** [sound/pci] Error 2
make: *** [sound] Error 2
Comment 110 John Feeney 2009-07-23 15:24:29 EDT
I have a Lynnfield system with an i386 version of 2.6.18-159.el5 and I have sound and recording with all three patches (id=354741, id=354812, and id=354856). 

Is this another Lynnfield versus Clarkdale issue?
Comment 111 John Villalovos 2009-07-23 16:07:35 EDT
After playing with alsamixer I got 32 bit (i686) to work with attachment 354741 [details], 354812 and 354856 applied.

So I have x86_64 and 32bit working with sound on the front panel.  On the back panel sound came out of the green, orange, and black connectors.
Comment 112 Wu Fengguang 2009-07-23 21:58:32 EDT
(In reply to comment #108)
> 
> It seems that two later patches (id=354812 and 354856) causes some problems (no
> audio output on our development systems - patch 354741 is OK). I would suggest
> to not merge these patches to rhel kernel until we figure what's wrong.  

What's your hardware, kernel and alsa-info? Thanks.
Comment 113 John Villalovos 2009-07-23 22:02:47 EDT
(In reply to comment #112)
> (In reply to comment #108)
> > 
> > It seems that two later patches (id=354812 and 354856) causes some problems (no
> > audio output on our development systems - patch 354741 is OK). I would suggest
> > to not merge these patches to rhel kernel until we figure what's wrong.  
> 
> What's your hardware, kernel and alsa-info? Thanks.  

Fengguang,

I reported issue with 32 bit.  But after using alsamixer to set levels I was able to play audio as described in Comment 111.
Comment 114 Wu Fengguang 2009-07-23 22:09:36 EDT
Created attachment 354954 [details]
fix ALSA compile error when CONFIG_SND_DEBUG=y

(#109) John, the attached patch fixed the compile errors. (Sorry for not mentioning it earlier!)
Comment 115 Wu Fengguang 2009-07-23 22:19:49 EDT
(In reply to comment #111)
> After playing with alsamixer I got 32 bit (i686) to work with attachment
> 354741 [details], 354812 and 354856 applied.
> 
> So I have x86_64 and 32bit working with sound on the front panel.  On the back
> panel sound came out of the green, orange, and black connectors.  

Thanks. You get sound in (green, orange, black) jacks, that's expected in
2-channel mode, or playing 6-channel audio stream in 6-channel mode. When
playing 8-channel audio stream in 8-channel mode, the rear (green, orange,
black, blue) jacks will all have sound.

I mean "speaker-test -c8" for producing the 8-channel audio stream,
and "amixer set 'Channel Mode' 8ch" for setting the 8-channel mode.

(In reply to comment #113)
> Fengguang,
> 
> I reported issue with 32 bit.  But after using alsamixer to set levels I was
> able to play audio as described in Comment 111.  

Ah, that's OK. Thanks for the clarification.
Comment 116 Jaroslav Kysela 2009-07-24 09:19:07 EDT
Notes:

It seems that all "no audio", messages "switching to polling mode" and initial mixer initialization issues (sometimes driver mixer controls should be touched to get sound manually) are caused by wrong communication with HDA codec (probably a timing or DMA caching issue for RIRBs):

Wrong:

send_cmd: 0x202f000a       # get PCM parameters for NID #2, codec#2
response: 0x80860101       # returned revision ID?

Good:

send_cmd: 0x202f000a
response: 0xe0560

Just adding 'udelay(100);' to begin of azx_send_cmd() routine in hda_intel.c cures this problem. But it's not really a good fix, just a quick workaround.

I have CONFIG_SND_DEBUG=n in my config to see timing problems.
Comment 117 Jaroslav Kysela 2009-07-24 09:27:59 EDT
Here is the minimal change to fix the RIRB read procedure:

--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -573,6 +573,7 @@ static void azx_update_rirb(struct azx *chip)
        if (wp == chip->rirb.wp)
                return;
        chip->rirb.wp = wp;
+       udelay(10);
                
        while (chip->rirb.rp != wp) {
                chip->rirb.rp++;

But the question is why only IbexPeak chipset has this timing problem? When is the right time to get RIRB value from DMA? It seems that WP index has been updated but DMA operation has not finished yet or a cache (CPU, chipset) was hit.
Comment 118 Jaroslav Kysela 2009-07-24 09:46:56 EDT
(In reply to comment #117)
> Here is the minimal change to fix the RIRB read procedure:
> 
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@ -573,6 +573,7 @@ static void azx_update_rirb(struct azx *chip)
>         if (wp == chip->rirb.wp)
>                 return;
>         chip->rirb.wp = wp;
> +       udelay(10);
> 
>         while (chip->rirb.rp != wp) {
>                 chip->rirb.rp++;
> 
> But the question is why only IbexPeak chipset has this timing problem? When is
> the right time to get RIRB value from DMA? It seems that WP index has been
> updated but DMA operation has not finished yet or a cache (CPU, chipset) was
> hit.  

This does not work also reliably. It seems that only 'udelay(100);' in azx_send_cmd() fixes codec access problem as noted in comment#116.
Comment 119 Jaroslav Kysela 2009-07-27 11:41:31 EDT
Further problem investigation:

It seems that incoming RIRB entries are interleaved with zero values. Unfortunately, these values are not expected and we cannot even skip them (because zero might be also good result from the read operation from HDA codec).

Good:


corb send: 76: 0x308f0009
new res: 76, 0x800080, 0x3
new res: 77, 0x0, 0x3         <--- zero value (where it does come from?) ignored
response: 0x800080
corb send: 77: 0x309f0009
new res: 78, 0xf00000, 0x3
response: 0xf00000
new res: 79, 0x0, 0x3
corb send: 78: 0x304f1c00
new res: 80, 0xf00000, 0x3
response: 0xf00000

Wrong:

corb send: 77: 0x309f0009
new res: 77, 0x0, 0x3         <--- zero value, but at wrong timing -> result
response: 0x0
corb send: 78: 0x304f1c00
new res: 78, 0xf00000, 0x3    <--- right result for corb cmd #77 not #78
response: 0xf00000
Comment 120 Don Zickus 2009-07-28 16:13:44 EDT
in kernel-2.6.18-160.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 122 DongpoLiu 2009-07-28 21:34:35 EDT
Regression test on 2.6.18-160.el5 (x86 and x86_64) + RHEL 5.4 SP3 (x86 and x86_64) OS with Clarkdale C0/IbxPeak B1 Piketon:
Back/Front Panel's Playback/Microphone Record is OK now.
Comment 123 John Feeney 2009-07-29 11:21:19 EDT
Confirm sound and record okay with 2.6.18-160.el5 on Lynnfield (rev 04) with i686 and x86_64 kernels. Also tested on Auburndale/Havendale Ibex Peak (rev 03) successfully too.
Comment 124 Wu Fengguang 2009-08-03 03:13:52 EDT
Created attachment 355958 [details]
Isolate codec command/response so that the Realtek audio won't be messed up by the broken HDMI codec
Comment 125 Wu Fengguang 2009-08-03 03:18:28 EDT
(In reply to comment #119)
> Further problem investigation:
> 
> It seems that incoming RIRB entries are interleaved with zero values.
> Unfortunately, these values are not expected and we cannot even skip them
> (because zero might be also good result from the read operation from HDA
> codec).

Good catch!

> Wrong:
> 
> corb send: 77: 0x309f0009
> new res: 77, 0x0, 0x3         <--- zero value, but at wrong timing -> result
> response: 0x0
> corb send: 78: 0x304f1c00
> new res: 78, 0xf00000, 0x3    <--- right result for corb cmd #77 not #78
> response: 0xf00000  

Given that this looks like a hardware bug and won't be fixed anytime soon,
I submitted a patch to isolate this HDMI HW bug, so that the legacy audio
won't be affected.
Comment 126 Cameron Meadors 2009-08-04 16:37:08 EDT
Moving to VERIFIED

I hear audio through the Front headphone jack and 2ch output jack in the rear using

 # aplay /usr/share/sounds/startup3.wav
Comment 128 John Villalovos 2009-08-18 22:18:17 EDT
*** Bug 507277 has been marked as a duplicate of this bug. ***
Comment 129 errata-xmlrpc 2009-09-02 04:25:30 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html

Note You need to log in before you can comment on or make changes to this bug.