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.
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?
Created attachment 350714 [details] codec#2 for RHEL Beta x86 OS from Lynnfield CPU
Created attachment 350715 [details] codec#3 for RHEL Beta x86 OS from Lynnfield CPU
Created attachment 350716 [details] dmesg of RHEL_5.4_Beta x86 OS from Lynnfiled CPU
(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.....
Created attachment 350720 [details] lspci-x86_RHEL_5.4_Beta from Lynnfield CPU
Created attachment 350721 [details] codec#3 for RHEL Beta x86_64 OS from Lynnfield CPU
Created attachment 350722 [details] codec#2 for RHEL Beta x86_64 OS from Lynnfield CPU
Created attachment 350723 [details] dmesg_x86_64_RHEL_5.4_Beta from Lynnfield CPU
Created attachment 350724 [details] lspci-x86_64_RHEL_5.4_Beta from Lynnfield CPU
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
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.
I will apply the patch and provide the rpms as quickly as soon as possible. (Thanks, Jaroslav)
Note that this blocks BZ 506196, which is a requirement for RHEL 5.4, so I set the blocker flag to "?"
The rpms with the patch provided by comment #12 can be found on my people page. See http://people.redhat.com/jfeeney/.bz509526
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).
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
(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
Regarding comment#16. Could you attach output from 'dmesg' and 'alsa-info.sh --no-upload' running John's kernel? Thank you.
Seth, Do you have any input on this bug?
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.
Regarding comment 19, where do I get the 'alsa-info.sh' script?
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.
Created attachment 350977 [details] file created by alsa-info.sh on Piketon system.
Created attachment 351012 [details] dmesg from Lynnfield with 2.6.18-157.el5jfeeney509526.1 x86 kernel
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.
(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.
(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
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.
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.
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.
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.
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.
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?".
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
(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
Created attachment 351437 [details] dmesg from Lynnfield with 2.6.18-157.el5jfeeney509526.1 x86 kernel, RHEL Snap1 OS
(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"?
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
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
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?
*** Bug 510324 has been marked as a duplicate of this bug. ***
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.
Created attachment 351705 [details] alsa-info output for x86_64 updated (C0) system that does not have sound.
(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?
(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.
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.
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.
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 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.
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).
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.
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.
(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.
(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.
(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 ????
(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.
> > > > 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.
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.
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.
Created attachment 354205 [details] alsa-info.sh txt when rhel5.4 has AZX_MAX_CODECS set to 3.
(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!
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
(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.
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
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]#
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
(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.
(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.
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 :)
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.
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
(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.
(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.
(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.
(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
(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.
(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
Sorry wrong paste: http://git.alsa-project.org/?p=alsa-kmirror.git;a=commitdiff;h=c12c9b0c0280317c05d615593f38ddb52a8083a7
Created attachment 354713 [details] IbexPeak audio patch for RHEL 5.4
Created attachment 354714 [details] IbexPeak audio patch for upstream 2.6.30
Created attachment 354715 [details] IbexPeak audio patch for sound-2.6 git tree
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.
(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.
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)
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?
(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 :)
(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.
(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.
> > 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.
(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.
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)
(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).
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.
(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.
(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.
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.
Testing of patch from Comment 97 works on both the Clarkdale and Lynnfield IbexPeak systems.
Record works with rear jack on Lynnfield along with sound output front and rear with patch from comment #97. Thanks to all. John
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)
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.
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
(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.
(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
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?
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.
(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.
(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.
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!)
(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.
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.
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.
(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.
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
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.
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.
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.
Created attachment 355958 [details] Isolate codec command/response so that the Realtek audio won't be messed up by the broken HDMI codec
(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.
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
*** Bug 507277 has been marked as a duplicate of this bug. ***
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