Bug 475251
| Summary: | ALSA Bug: sound doesn't work in Fedora 10 (and didn't work in later kernels in Fedora 9) | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Aditya Kadambi <rakadambi> |
| Component: | alsa-lib | Assignee: | Jaroslav Kysela <jkysela> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 10 | CC: | jkysela, kernel-maint, maurizio.antillon, quintela, rhughes, wolfgang.rupprecht |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: |
uname -a
Linux localhost 2.6.27.5-117.fc10.x86_64 #1 SMP Tue Nov 18 11:58:53 EST 2008 x86_64 x86_64 x86_64 GNU/Linux
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-03-17 14:03:46 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
|
Description
Aditya Kadambi
2008-12-08 17:27:06 UTC
Latest fedora kernel: Linux localhost 2.6.27.7-134.fc10.x86_64 #1 SMP Mon Dec 1 22:21:35 EST 2008 x86_64 x86_64 x86_64 GNU/Linux Same results. No sound. As bad as ever. Kernel version on which sound worked: 2.6.25-14.fc9.x86_64 I think sound stopped working after 2.6.26 series hit Fedora 9. I added one thread at FedoraForum.org linked below, just read the responses. http://forums.fedoraforum.org/showthread.php?t=205685&goto=newpost Will this get any attention? It clearly looks like a regression. Can this get some attention, please? With the latest kernel update: 2.6.27.9-159.fc10.x86_64, no sound. dmesg doesn't give any stacktrace. Only this: ALSA sound/core/pcm_native.c:2041: snd_pcm_hw_constraints_complete failed This bug report says it should be fixed. But it doesn't seem to be: http://bugzilla.kernel.org/show_bug.cgi?id=11643 Will the high priests take a look at this? I created a bug report at ALSA project since nobody here gives a damm. https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4321 1.0.19. No Sound still. Amazing incompetence. Wow! new kernel and repeat of same dmesg ALSA sound/core/pcm_native.c:2046: snd_pcm_hw_constraints_complete failed ALSA sound/core/pcm_native.c:1940: BUG? (err >= 0) Pid: 2678, comm: pulseaudio Not tainted 2.6.27.12-170.2.5.fc10.x86_64 #1 Call Trace: [<ffffffffa015751f>] snd_pcm_hw_constraints_complete+0xc2/0x2bc [snd_pcm] [<ffffffffa015778b>] snd_pcm_open_substream+0x72/0xb3 [snd_pcm] [<ffffffffa0157890>] snd_pcm_open+0xc4/0x1cb [snd_pcm] [<ffffffff8103a651>] ? default_wake_function+0x0/0xf [<ffffffffa01579c6>] snd_pcm_capture_open+0x2f/0x34 [snd_pcm] [<ffffffffa01145f5>] snd_open+0xe7/0x156 [snd] [<ffffffff810c2d6d>] chrdev_open+0x14a/0x169 [<ffffffff810c2c23>] ? chrdev_open+0x0/0x169 [<ffffffff810beb9a>] __dentry_open+0x13a/0x249 [<ffffffff810bed5f>] nameidata_to_filp+0x2e/0x40 [<ffffffff810ca0c3>] do_filp_open+0x3e4/0x7db [<ffffffff81031083>] ? need_resched+0x1e/0x28 [<ffffffff8133196a>] ? _cond_resched+0x9/0x38 [<ffffffff8116e314>] ? __strncpy_from_user+0x2c/0x53 [<ffffffff810d4c79>] ? alloc_fd+0x110/0x123 [<ffffffff810be9a3>] do_sys_open+0x53/0xd3 [<ffffffff810bea4c>] sys_open+0x1b/0x1d [<ffffffff8101024a>] system_call_fastpath+0x16/0x1b ALSA sound/core/pcm_native.c:2046: snd_pcm_hw_constraints_complete failed Assholes don't even care. I don't want to be nice to these "developers" Aditya, You have to bear in mind that Fedora (the distro) is made up of lots of different teams working on upstream software. We only have a few people (1?) working on "alsa" for Fedora whilst there are many hundreds on the upstream mailing list. The way I would have tried to fix this would be to open a bug upstream with ALSA, and then work with upstream. Once upstream is fixed, open a bug here asking somebody to patch the kernel with the hot-fix until we get the fixed kernel in a few weeks time. As maintainers, we get hundreds of bug reports every day, some valid, some invalid. Ranting about us being Assholes certainly won't speed things along. I'm sorry. I offer unqualified apologies. Months and months and months. No sound. I have forgotten the time when "standard" things like sound worked on Fedora. Just plugged in another box (i686) running Fedora 9 and it took 2.6.27.xx and sound failed on that too. Ah well... OK, he last kernel that worked was: 2.6.25.11-97. OK. I got alsa-driver-20090213.tar.bz2 from kernel.org, compiled it with --with-debug=verbose. When I loaded the module, these are the messages, I got: ALSA /home/rak/Download/alsa-driver/pci/hda/hda_intel.c:2218: chipset global capabilities = 0x4401 ALSA /home/rak/Download/alsa-driver/pci/hda/hda_intel.c:786: codec_mask = 0x1 ALSA /home/rak/Download/alsa-driver/pci/hda/hda_intel.c:1214: hda_intel: codec #0 probed OK ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:2725: hda_codec: model '3stack-6ch-dig' is selected input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:14.2/input/input6 ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:1371: Cannot find slave Side Playback Volume, skipped ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:1371: Cannot find slave Headphone Playback Volume, skipped ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:1371: Cannot find slave Speaker Playback Volume, skipped ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:1371: Cannot find slave Mono Playback Volume, skipped ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:1371: Cannot find slave Line-Out Playback Volume, skipped ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:1371: Cannot find slave PCM Playback Volume, skipped ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:1371: Cannot find slave Side Playback Switch, skipped ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:1371: Cannot find slave Speaker Playback Switch, skipped ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:1371: Cannot find slave Mono Playback Switch, skipped ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x8 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x8 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x8 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x8 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x8 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x8 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x8 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x2 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x2 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x2 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x2 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x2 ALSA /home/rak/Download/alsa-driver/acore/pcm_native.c:2050: snd_pcm_hw_constraints_complete failed ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:895: hda_codec_cleanup_stream: NID=0x2 kernel maintainers automatically get copies of kernel-maint messages... On Alsa bug tracker, "Raymond" mentioned these two patches: http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=11370ee2c1c578a704f47d5513d57274c335db43 Could this patch be causing it? http://git.alsa-project.org/?p=alsa-kernel.git;a=commit;h=f32a19e3e7e72cc896d02c3d104f58dc972d43ea I have posted other info over there too. Will the developers please please please please look into this. It has been very long since I have had sound. Please! OK, I have determined the failure is in the 64 bit systems in this function in alsa-kernel/core/pcm_lib.c: function snd_pcm_hw_constraint_mask64: In snd_pcm_hw_constraint_mask64: Before memset: maskp->bits[0] = 0, maskp->bits[1] = 0 In snd_pcm_hw_constraint_mask64: After memset: maskp->bits[0] = 0, maskp->bits[1] = 0 Hence it returns -EINVAL. Will Jaroslav Kysela please take a look at this. I can do some more debugging if you tell me where to look for. PLEASE! Created attachment 335179 [details]
alsa-info for failing sound on Asus M3A78-T
Another 64-bit system with an intel azalia subsystem that fails to play sound due to severely low volume. With external speakers one can turn the volume all the way up on the board and on the speakers and hear *some* sound.
mask64 is used to set value from runtime->hw.formats . Could you check this value in azx_pcm_open() function? File pci/hda/hda_intel.c . Also, if it's zero, then look to snd_hda_query_supported_pcm() function in hda_codec.c - print rates value at the end of "if (ratep)" block. wolfgang: no idea, try hda-analyzer (see www.alsa-project.org for more details) to play with codec registers directly Thanks! thanks! for the response. (In reply to comment #22) > mask64 is used to set value from runtime->hw.formats . Could you check this > value in azx_pcm_open() function? File pci/hda/hda_intel.c . It is set to 0. > Also, if it's zero, then look to snd_hda_query_supported_pcm() function in > hda_codec.c - print rates value at the end of "if (ratep)" block. Did you mean ratesp? There isn't a ratep variable in that function. If it is ratesp, this is the result of my printk in this block: -------------------------------------------------------------------------- if (ratesp) { u32 rates = 0; for (i = 0; i < AC_PAR_PCM_RATE_BITS; i++) { if (val & (1 << i)) rates |= rate_bits[i].alsa_bits; } *ratesp = rates; printk(KERN_INFO "Value of ratesp in function %s is %#x\n", __FUNCTION__, *ratesp); } ---------------------------------------------------------------------------- Value of ratesp in function snd_hda_query_supported_pcm is 0x14c0 Value of ratesp in function snd_hda_query_supported_pcm is 0x2 Value of ratesp in function snd_hda_query_supported_pcm is 0x14c0 Value of ratesp in function snd_hda_query_supported_pcm is 0x14c0 Value of ratesp in function snd_hda_query_supported_pcm is 0x4c0 Value of ratesp in function snd_hda_query_supported_pcm is 0x14c0 OK, yes ratesp is correct name. No zero there, so I wonder who zeroed this value.
Please, add printk for nid to ratesp in snd_hda_query_supported_pcm and azx_pcm_open (hinfo->nid value).
Also, change snd_pcm_set_ops block to something like this in azx_attach_pcm_stream (hda_intel.c):
if (cpcm->stream[s].substream) {
printk(KERN_INFO "attach_pcm: nid=0x%x, formats=0x%x\n", apcm->hinfo[s].nid, apcm->hinfo[s].formats);
snd_pcm_set_ops(pcm, s, &azx_pcm_ops);
}
(In reply to comment #25) > OK, yes ratesp is correct name. No zero there, so I wonder who zeroed this > value. > > Please, add printk for nid to ratesp in snd_hda_query_supported_pcm and > azx_pcm_open (hinfo->nid value). Added this printk: printk(KERN_INFO "Value of ratesp and nid in function %s: ratesp = %#x, nid = %#x\n", __FUNCTION__, *ratesp, nid); Output is: Value of ratesp and nid in function snd_hda_query_supported_pcm: ratesp = 0x14c0, nid = 0x2 Value of ratesp and nid in function snd_hda_query_supported_pcm: ratesp = 0x2, nid = 0x8 Value of ratesp and nid in function snd_hda_query_supported_pcm: ratesp = 0x14c0, nid = 0x6 Value of ratesp and nid in function snd_hda_query_supported_pcm: ratesp = 0x14c0, nid = 0xa Value of ratesp and nid in function snd_hda_query_supported_pcm: ratesp = 0x4c0, nid = 0x9 Value of ratesp and nid in function snd_hda_query_supported_pcm: ratesp = 0x14c0, nid = 0x6 Added this printk in azx_pcm_open printk(KERN_INFO "Value of runtime->hw.formats and hinti->nid in function %s: runtime->hw.formats = %llu, hinfo->nid = %#x\n", __FUNCTION__, runtime->hw.formats, hinfo->nid); Output is: Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x2 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x2 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x2 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x2 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x2 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x2 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x2 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x8 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x8 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x8 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x8 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x8 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x8 Value of runtime->hw.formats and hinti->nid in function azx_pcm_open: runtime->hw.formats = 0, hinfo->nid = 0x8 > > Also, change snd_pcm_set_ops block to something like this in > azx_attach_pcm_stream (hda_intel.c): > > if (cpcm->stream[s].substream) { > printk(KERN_INFO "attach_pcm: nid=0x%x, formats=0x%x\n", apcm->hinfo[s].nid, > apcm->hinfo[s].formats); > snd_pcm_set_ops(pcm, s, &azx_pcm_ops); > } The output for this is: attach_pcm: nid=0x2, formats=0x0 attach_pcm: nid=0x8, formats=0x0 attach_pcm: nid=0x6, formats=0x40404 attach_pcm: nid=0xa, formats=0x40404 attach_pcm: nid=0x9, formats=0x404 Created attachment 335389 [details]
Show proper error message for bad rates/formats in hda_codec
Please, try patch from comment#27 and attach error messages. It failed in the formats == 0 section. The rates == 0 section seem to have succeeded. Output: ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:2612: hda_codec: formats == 0 (nid=0x2, val=0xe0560, ovrd=1, streams=0xe0560) Interesting, val should not be equal to streams... it looks like that streams value is broken.. Could you duplicate "streams = snd_hda_param_read(codec, nid, AC_PAR_STREAM);" in snd_hda_query_supported_pcm() function? I don't understand the question! How do you "duplicate" that function call? I see calls like this in the function snd_hda_query_supported_pcm() streams = snd_hda_param_read(codec, nid, AC_PAR_STREAM); Do you want me to print the values of "streams"? Just write same line bellow in the source file to read value from hardware twice: streams = snd_hda_param_read(codec, nid, AC_PAR_STREAM); streams = snd_hda_param_read(codec, nid, AC_PAR_STREAM); I duplicated the function call as per below:
if (formatsp || bpsp) {
u64 formats = 0;
unsigned int bps;
unsigned int wcaps;
wcaps = get_wcaps(codec, nid);
streams = snd_hda_param_read(codec, nid, AC_PAR_STREAM);
streams = snd_hda_param_read(codec, nid, AC_PAR_STREAM);
if (streams == -1)
return -EIO;
if (!streams) {
streams = snd_hda_param_read(codec, codec->afg, AC_PAR_STREAM);
streams = snd_hda_param_read(codec, codec->afg, AC_PAR_STREAM);
if (streams == -1)
return -EIO;
}
These are the results:
ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:2616: hda_codec: formats == 0 (nid=0x8, val=0x1, ovrd=1, streams=0x1)
Created attachment 335497 [details]
Show error messages in snd_hda_query_supported_pcm() and reorder local variables declaration
Please, test patch from comment#34 . I applied the patch. The results seem to look like before: Output: ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:2617: hda_codec: formats == 0 (nid=0x2, val=0xe0560, ovrd=1, streams=0xe0560) Created attachment 335511 [details]
Test patch
Ok, added more printk-s to show timing. Please show output from patch from comment#37. But I'm getting out of ideas - how can be val == streams in your all test outputs? GCC bug? OK, it seems to "read" the same value for val and streams. A1: val = 0x0, streams = 0x0 A2: val = 0x0, streams = 0x0 A3: val = 0xe0560, streams = 0x0 A4: val = 0xe0560, streams = 0x0 A5: val = 0xe0560, streams = 0xe0560 A6: val = 0xe0560, streams = 0xe0560 A7: val = 0xe0560, streams = 0xe0560 ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:2624: hda_codec: formats == 0 (nid=0x2, val=0xe0560, ovrd=1, streams=0xe0560) My gcc is: Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-cpu=generic --build=x86_64-redhat-linux Thread model: posix gcc version 4.3.2 20081105 (Red Hat 4.3.2-7) (GCC) Created attachment 335514 [details]
Test patch #2
Yes, now try a little bit modified patch from comment#40. I don't understand why val == 0x01 in your comment#33 and not 0xe0560. This is the output: The values seem to be shifting: A1: val = 0x0, streams = 0x0 A2: val = 0x0, streams = 0x0 A3: val = 0xe0560, streams = 0x0 A4: val = 0xe0560, streams = 0x0 A5: val = 0xe0560, streams = 0xe0560 A5-1: val = 0xe0560, streams = 0x1 A6: val = 0xe0560, streams = 0x1 A7: val = 0xe0560, streams = 0x1 A1: val = 0x0, streams = 0x0 A2: val = 0x1, streams = 0x0 A3: val = 0x1, streams = 0x0 A4: val = 0x1, streams = 0x0 A5: val = 0x1, streams = 0x60160 A5-1: val = 0x1, streams = 0x1 A6: val = 0x1, streams = 0x1 A7: val = 0x1, streams = 0x1 ALSA /home/rak/Download/alsa-driver/pci/hda/../../alsa-kernel/pci/hda/hda_codec.c:2628: hda_codec: formats == 0 (nid=0x8, val=0x1, ovrd=1, streams=0x1) Could you try pass 'single_cmd=1' module option to snd-hda-intel ? modprobe snd-hda-intel single_cmd=1 I actually have the option now. Without that option, the sound card is not recognized. I'm sorry, I overlooked this in your report. Do you have more than 4GB RAM, right? In this case the bug seems duplicate to bug#489828 where a fix is also proposed. Actually we integrating this fix to the ALSA driver tree. Also, do not use 'single_cmd' after applying the code from bug#489828 . Please, report back your result. BTW: New driver snapshot from http://www.alsa-project.org/snapshot/ should have this issue also fixed. Wow! I applied these lines and disabled single_cmd=1 in modprobe.conf and sound is back!
< if ((gcap & 0x01) && !pci_set_dma_mask(pci, DMA_64BIT_MASK))
< pci_set_consistent_dma_mask(pci, DMA_64BIT_MASK);
---
> /* if ((gcap & 0x01) && !pci_set_dma_mask(pci, DMA_64BIT_MASK))
> pci_set_consistent_dma_mask(pci, DMA_64BIT_MASK); */
> pci_set_dma_mask(pci, DMA_32BIT_MASK);
> pci_set_consistent_dma_mask(pci, DMA_32BIT_MASK);
Thank you! thank you! thank you! thanks a ton!! I really appreciate this!
*** This bug has been marked as a duplicate of bug 489828 *** |