Bug 507088

Created attachment 348751 [details]
lspci -v

Created attachment 348752 [details]
'pulseaudio -vvv' for crash with hard cpu limit, case "B) a)"

Created attachment 348753 [details]
'pulseaudio -vvv' for crash with assertion 'pa_idxset_isempty(c->clients)', case "B) b)"

Created attachment 348754 [details]
'pulseaudio -vvv' for crash with "alsa-source.c: Thread shutting down", case "B) c)"

Created attachment 348755 [details]
'pulseaudio -vvv' for crash with "W: protocol-native.c: Failed to push data into queue", case "A)"

Hmpf, may I kindly ask you to reattach those logs uncompressed as text/plain? It's very painful to read through them like this.

Also, please include an output of "pacmd ls".

The snd_pcm_mmap_commit() is almost certainly a driver issue.

Created attachment 349786 [details]
Uncompressed case B) a)

Created attachment 349787 [details]
Uncompressed case B) b)

Created attachment 349788 [details]
Uncompressed case B) c)

Created attachment 349789 [details]
Uncompressed case A)

Created attachment 349790 [details]
output of "pacmd ls"

Created attachment 350083 [details]
pulseaudio -vvvv log, 2.6.29.5-191.fc11.x86_64, default configuration

Can't reproduce the crash after an update to 2.6.29.5-191.fc11.x86_64.
Flood of under-runs still present.
Streams still go silent but PA tends to recover after closing both players.

I've noticed that PA is a bit more resilient when I remove the 'alsa-plugins-pulseaudio' package (regardless of other ALSA applications running during the test).
With the package installed, PA will hang and start the under-run flood much quicker (sometimes the moment the second player is started). Sound crackles under I/O and even light load.

Without the package, PA hangs after "wiggling" a seek slider.

Happens to me too, same kernel, alsa-plugins-pulseaudio installed.  I have tsched=0 in default.pa on a Dell OptiPlex GX620 with a Intel 82801G (ICH7 Family) AC'97 Audio Controller (rev 01).  Got the "memblock.c: Assertion 'length' failed at pulsecore/memblock.c:356, function pa_memblock_new_fixed(). Aborting" message.

Created attachment 355453 [details]
Logs and configuration of my system

Happens also to me. Just using amarok or audacious after a while recreates the problem. 

The problems appeared after installing the latest updates that were available from 18-27 July (about 150 packages). My repolist and versions of possible affecting packages are included in the attached file. Before updating the system, the sound worked perfectly.

System details:

[iliverez@guybrush log]$ uname -a
Linux guybrush.localdomain 2.6.29.6-213.fc11.x86_64 #1 SMP Tue Jul 7 21:02:57 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

[iliverez@guybrush log]$ lspci
00:04.0 Multimedia audio controller: nVidia Corporation CK804 AC'97 Audio Controller (rev a2)

I attach a file with the following content:
 - output of "pacmd -ls"
 - excerpt of "/var/log/messages", when the problem happens
 - contents of /etc/pulse/default.pa
 - Installed relevant packages
 - Installed repositories

I downgraded to pulseaudio-0.9.15-11.fc11.x86_64 (and pulseaudio-libs etc.) and the problem continued to exist.
Then I also reverted back to previous kernel 2.6.29.5-191.fc11.x86_64 and things seem to work ok now.

With 2.6.29.6-213 the problem would occur at most after 5 mins of audio playback or almost immediately on .avi files playback with totem.

Trying with 2.6.29.5-191.fc11.x86_64 no problems after ~1hour avi playback with totem and 1h audio (mp3) playback with audacious. No problems with load, no cracking sounds at heavy CPU or hard disk IO load. Going back to pulseaudio-0.9.15-14 also worked fine with kernel 2.6.29.5-191.fc11.x86_64.

@Henrique: Could you please clarify to what version "same kernel" refers to? Is it 4-167 or 5-191? With 2.6.29-6.213, I got the same issue with you (pulsecore/memblock.c:356). Could you provide the driver that is used for you hardware? You can see it with "lspci -v" or "lsmod".

@Lukasz: My hardware uses the snd-intel8x0 driver, not snd-hda-intel. However, I see similarities in my case with both your post (case B,e) and Henrique's case. I cannot recall facing any problem with kernel 4-167. It may be a common problem, exposed with 2.6.29-4-167 with snd-hda-intel in your case and kernel 2.6.29-6-213 and snd-intex8x0 driver in my case. Does kernel 2.6.29-213 work well for you?

Possibly, looking the diffs of snd-hda-intel in kernels 2.6.29-4.167 and 2.6.29-5.191 and snd-intel8x0 in kernels 2.6.29-5.191 and 2.6.29-6-213 could lead to something useful.

Same kernel back then referred to 2.6.29.5-191.fc11.i586.  I'm now on 2.6.29.6.-213.fc11.i586 but haven't been on that machine long enough to notice whether the problem is gone or not.
I'll attach the output of lspci -v and lsmod next.

Created attachment 355486 [details]
output of lspci -v

Created attachment 355487 [details]
output of lsmod

I still get the error flood like in case "B) a)" with kernel version 2.6.29.6-213. Playback doesn't go silent as in my previous comment and PA doesn't die as easily. Rewinding produces lots of clicks instead of crashing the PA daemon so it's a definite improvement. :)

Sometimes the daemon does die because of the CPU limit during the test case but it's hardly predictable. Compared to the previous kernel version it's rare.

Taking diffs between the various kernel versions in the whole sound dir, I could not find any changes in the related drivers. However, I found an interesting change in kernel-2.6.29-5 and kernel 2.6.29-6 in sound/pci/hda/hda_codec.c in function snd_hda_codec_write_cache:


** sound/pci/hda/hda_codec.c   2009-06-15 19:44:45.000000000 +0300
--- ../../6-213/linux-2.6.29/sound/pci/hda/hda_codec.c  2009-03-24 01:12:14.000000000 +0200
***************
*** 2003,2013 ****
    err = bus->ops.command(bus, res);
    if (!err) {
        struct hda_cache_head *c;
!       u32 key;
!       /* parm may contain the verb stuff for get/set amp */
!       verb = verb | (parm >> 8);
!       parm &= 0xff;
!       key = build_cmd_cache_key(nid, verb);
        c = get_alloc_hash(&codec->cmd_cache, key);
        if (c)
            c->val = parm;
--- 2003,2009 ----
    err = bus->ops.command(bus, res);
    if (!err) {
        struct hda_cache_head *c;
!       u32 key = build_cmd_cache_key(nid, verb);
        c = get_alloc_hash(&codec->cmd_cache, key);
        if (c)

In the older versions 4.167 and 5.191, variable parm would be effectively reduced to a byte due to the applied mask 0xff, whereas in the newer version the whole content of parm is used. 

I have no idea yet if this part of code is actually used in this issue (if it is used by the hda_intel, intel8x0 and via82xx drivers) or even if there is something wrong with this change.

One more point, if of any help, is that when the problem occured with 2.6.29-213, the progress bar of the player (totem, audacious, amarok), both on video and audio files, would skip long parts of the media file, to end up to stopping playback or crashing. Thus, a seven minutes song would be reduced to a couple of seconds and then crash.

Anything I can do to help? 

Intel ICH6 with AD1981B Sound Card
IBM Thinkpad X41
kernel-2.6.29.6-213.fc11

Started for me in the last few days, and now happens consistently, preventing audio from playing from Rhythmbox, mplayer, or Flash plugin to completion.  Not sure if it's related, but the audio slider argues with me: I tell it to be set to half, and it decides it really wants to appear to be set to max.

Same thing here.  I can't get through an Onpoint podcast without pulseaudio crashing:

Aug 11 02:57:31 gauge pulseaudio[4493]: memblock.c: Assertion 'length' failed at pulsecore/memblock.c:356, function pa_memblock_new_fixed(). Aborting.

kernel-2.6.29.6-217.2.3.fc11.i686.PAE

00:1f.5 Multimedia audio controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller (rev 02)
        Subsystem: Dell Device 0162
        Flags: bus master, medium devsel, latency 0, IRQ 17
        I/O ports at ee00 [size=256]
        I/O ports at edc0 [size=64]
        Memory at febffa00 (32-bit, non-prefetchable) [size=512]
        Memory at febff900 (32-bit, non-prefetchable) [size=256]
        Capabilities: <access denied>
        Kernel driver in use: Intel ICH
        Kernel modules: snd-intel8x0

Hi all,

my previous comment (#21) was completely wrong. I somehow messed up extracting the source RPMs of the various kernel versions. 

Anyway, the problem lies in the changes of sound/core/pcm_lib.c. The last good working version for my hardware was 2.6.29-5.191. I copied the pcm_lib.c file into the 2.6.29-6.217.2.3 kernel source and rebuilt the kernel, and everything works fine again. 

I am not familiar with the architecture of the sound stack in the kernel and with how audio hardware works in general, but I am quite sure that the people that made the changes that introduced this problem had a lot of good reasons to do so. Therefore, I kindly ask, if possible, someone that has this knowledge and experience (possibly Lennart?) to review again those changes in pcm_lib.c and provide the best solution. 

In the following posts I send the modified spec file and the patch for pcm_lib.c for the kernel (2.6.29-6.217.2.3), in case someone wants to experiment, rebuild the kernel and try. 
Instructions for building a custom kernel can be found here:
http://fedoraproject.org/wiki/Docs/CustomKernel

If you think that it would be useful to upload the built rpms (x86_64) somewhere for other people to use, feel free to contact me. 
Once again, I would prefer that someone that knows well this topic takes care to build official packages, after pcm_lib.c has been revised.

Created attachment 357253 [details]
Patch for sound/core/pcm_lib.c for kernel-2.6.29.6-217.2.3

This patch reverts pcm_lib.c of kernel-2.6.29.6-217.2.3 to the one of 2.6.29.5.191. It addresses #507088 and seems that problems with xruns, large chunk skipping, segfaults of applications that use audio have been fixed.

Created attachment 357255 [details]
Modified spec file to apply the patch fix-pcm-lib-iliverez.patch

This spec file should be used to rebuild kernel-2.6.29.6.217.2.3 with the fix-pcm-lib-iliverez.patch. It also generates by default the corresponding kernel-firmware package.

Yannis, is it possible that your issue is already covered in bug 506075?

Yes, I think so. I have missed 506075 in my initial search in the bug tracker. I found out about this bug today. I 've posted about this possibility in bug 516649 a couple of hours ago. I think also 516649 is a duplicate of 506075. 

However, 506075 provides a solution only for intel_8x0 (which actually covers me).
I wonder if reverting pcm_lib.c could temporarily help with via82xx or intel_hda, or better if it could lead to a fix for those drivers.

Turns out that, in my case, the problem didn't really go away. It happened on two occasions with the latest kernel update 2.6.29.6-217.2.8.fc11.x86_64. Symptoms were as in comment #12. (PA didn't crash but one stream went silent)

I found something that might have triggered the instability from my original bug report.
--
hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
--
This warning is very rare but when it showed up today in dmesg (during boot), pulseaudio stuttered as in my original report and stopped due to CPU overload when I followed the usual steps.

The warning didn't show up when I rebooted and the symptoms were gone.
I tried to look in hda_intel.c for the cause of the warning but I have no
experience in linux kernel programming. It looks like it's something in the ALSA driver that's causing this instability in PA.

I'm fairly sure the problems everyone but Lukasz reported are different, because other reporters seem to say the problem _started_ after a kernel update, whereas for Lukasz he always had the problem from the start of F11, and kernel updates _improved_ the situation. They could be similar bugs, but they don't seem to be the same. So, other reporters, please check and see if your reports are genuine dupes of others - such as 506075 which Lennart mentioned - or file new reports.

Lukasz, how are things with current F11? Kernel went to 2.6.30, so the situation may have changed, I guess. If there's still problems, can we get updated pulseaudio logs so Lennart can assess the situation? Thanks.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Nothing changed since my last comment, I'm afraid. I've been trying to trigger that warning under heavy CPU/disk/network and wireless usage but had no luck. After everything I've tried it seems the warning can show up at completely random times (during boot, after an hour or a few days of uptime). Is there a way to get some more debugging info for that warning?

I've successfully reproduced the bug with the kernel version 2.6.30.9-90.fc11.x86_64.

Created attachment 367488 [details]
pulseaudio -vvvv log, 2.6.30.9-90.fc11.x86_64, default configuration

This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I still see pulseaudio die on f12, though I'm not sure if it's under load or randomly.

kernel-2.6.32.11-99.fc12.x86_64
pulseaudio-0.9.21-5.fc12.x86_64

adjusting to 12, then. thanks.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.