How to diagnose crashes in Manjaro ARM (potential ALSA bug)?

I have been using Manjaro ARM 19.08 for a couple of days now on a Raspberry Pi 4 with 2GB RAM. It's a bit sluggish, but disabling display compositing did help. I did a full update with sudo pacman -Syyu.

But the bigger issue for me is that it has crashed about 4 times over that time period and a restart is the only recovery.

I'm going to be keeping more of an eye on what I am doing at the time of the crash.

Regardless the audio has been choppy.

Is this something that others are getting? How can I diagnose this?

Here are the most recent errors from,

journalctl | grep fail

Oct 13 10:59:03 pi4 dbus-daemon[299]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.
Oct 13 10:59:32 pi4 blueman-mechani[718]: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
Oct 13 12:09:48 pi4 dbus-daemon[299]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service not found.
Oct 13 12:19:35 pi4 kernel: Bluetooth: hci0: sending frame failed (-49)
Oct 13 12:19:36 pi4 dbus-daemon[299]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Refusing activation, D-Bus is shutting down.
Oct 13 12:19:36 pi4 dbus-daemon[299]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.nm-dispatcher.service': Refusing activation, D-Bus is shutting down.
Oct 13 15:03:41 pi4 NetworkManager[296]: [1570932221.8489] sup-iface: failed to cancel p2p connect: P2P cancel failed
Oct 13 15:03:46 pi4 dbus-daemon[295]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.resolve1.service': Unit dbus-org.freedesktop.resolve1.service not found.
Oct 13 15:37:40 pi4 blueman-mechani[794]: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed

journalctl | grep error

Sep 24 11:53:53 pi4 kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
Sep 24 11:53:53 pi4 kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
Oct 13 10:47:58 pi4 pulseaudio[542]: ICE default IO error handler doing an exit(), pid = 542, errno = 11
Oct 13 10:48:00 pi4 unknown[579]: xfce4-notifyd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Oct 13 10:58:55 pi4 pulseaudio[597]: ICE default IO error handler doing an exit(), pid = 597, errno = 11
Oct 13 10:58:55 pi4 unknown[634]: xfce4-notifyd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.
Oct 13 12:19:33 pi4 unknown[629]: xfce4-notifyd: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.

dmesg | grep fail

[ 0.963893] bcmgenet fd580000.genet: failed to get enet clock
[ 0.967575] bcmgenet fd580000.genet: failed to get enet-wol clock
[ 0.969371] bcmgenet fd580000.genet: failed to get enet-eee clock
[ 6.218526] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[ 6.218545] cfg80211: failed to load regulatory.db

dmesg | grep error

[ 6.218526] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2

UPDATE:

The last error before my latest crash with journalctl is this,

-- Reboot --
Oct 13 20:22:51 pi4 pulseaudio[590]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: snd_pcm_delay() returned a value that is exceptionally large: -663964 bytes >
-- Reboot --

Oh, and look at this a bit earlier prior to a previous reboot,

Oct 13 15:20:42 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: snd_pcm_delay() returned a value that is exceptionally large: -19456860 bytes (-101337 ms).
Oct 13 15:20:42 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: Most likely this is a bug in the ALSA driver 'snd_bcm2835'. Please report this issue to the ALSA developers.
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: snd_pcm_dump():
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: Hardware PCM card 0 'bcm2835 ALSA' device 0 subdevice 0
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: Its setup is:
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: stream : PLAYBACK
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: access : MMAP_INTERLEAVED
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: format : S16_LE
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: subformat : STD
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: channels : 2
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: rate : 48000
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: exact rate : 48000 (48000/1)
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: msbits : 16
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: buffer_size : 32768
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: period_size : 32768
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: period_time : 682666
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: tstamp_mode : ENABLE
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: tstamp_type : MONOTONIC
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: period_step : 1
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: avail_min : 32768
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: period_event : 0
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: start_threshold : -1
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: stop_threshold : 4611686018427387904
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: silence_threshold: 0
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: silence_size : 0
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: boundary : 4611686018427387904
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: appl_ptr : 5088
Oct 13 15:22:34 pi4 pulseaudio[588]: E: [alsa-sink-bcm2835 ALSA] alsa-util.c: hw_ptr : 0
-- Reboot --

I'll keep an eye out at these logs, because if I am getting this around the time of crashes it points to the ALSA driver as the issue.

Any further help I can be let me know.

I have a RPi4 with 4G ram and I am not getting any crashes using Mate, XFCE or KDE Plasma. I do though on my pi3b+ with 1G RAM especially using Firefox. Have you been monitoring your RAM usage? V3D along with a 64bit OS will use more RAM than a 32bit OS.

The following removes random audio crackling while playing videos. Find these lines in: /etc/pulse/default.pa

### Automatically load driver modules depending on the hardware available
.ifexists module-udev-detect.so
load-module module-udev-detect
.else

and change the text in the line that starts with "load-module" to read this and reboot:

load-module module-udev-detect tsched=0`

Other than that I have no alsa related issues.

Yeah, firefox is a problem. Is there a more light weight browser that works on ARM? I have been googling it, and I haven't found anything other than chromium that is supported on ARM.

For instance here are some that are mentioned,

But I guess firstly that is out of date. But next, something like Midori is mentioned there, but I coudn't get it to install, it just says that there is not an ARM 64 package.

I think you are right though, it is memory related. E.g. I had htop open and it froze when I got to about 1.6 / 1.8 memory used. The problem with that is it doesn't take many firefox tabs being opened to get to that point, e.g. 5, 6.

Whereas something like FFMpeg, FFPlay are light, you can have a bunch of them going and no problem.

I never found any browser that very worked with my RPi3b+ and aarch64. I tried midori and hated it and was not much better. I just stopped using a browser and avoided things like libreoffice, gimp...

Playing satellite streams with out gpu hardware decoding was a pain also but it does stream well over the lan to my desktop where I could use vlc.

You can create a swapfile to stop freezing. When it starts using the swapfile things slow down to a crawl but will allow you to gracefully exit programs and reboot.

sudo fallocate -l 512M /swapfile
sudo dd if=/dev/zero of=/swapfile bs=1M count=512
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile    # Makes Effective temporarily
 
# sudo nano /etc/fstab and add this line to the bottom:
 
/swapfile none swap defaults 0 0

After creating the swapfile above another thing I had done is force it to use 90% of the available ram by adjusting the swapiness.

sudo sysctl vm.swappiness=10   # Makes Effective temporarily
 
# Make permanent
# sudo nano /etc/sysctl.d/99-sysctl.conf and add this:
 
vm.swappiness=10

Sounds like @Strit needs to take a look at that package.

Why does it crawl, mainly just because the SD card is slow? Could you install swap on a USB drive or SSD drive?

In that case could you install the OS on a couple of USB drives, one for OS, and the other for swap? Or an old SSD?

Also you mentioned Mate above, how do you install Mate, and is it any less intensive than XFCE?

Yes the sdcard is slow and a fast usb 3.0 stick is a little better and SSD but neither will be as fast as using the onboard ram.

Yes to installing on a usb ideally using a fast usb 3.0 stick pluged into the pi's 3.0 port. I see no reason not to use a SSD drive as long as it is self powered.

The RPi4 will not boot yet straight to a usb stick or a SSD drive. But it can boot on the sdcard's boot partition and then use a usb stick or SSD drive for the root partition. You have to find out the drive's partition designation make an adjustment in the /boot/cmdline.txt file with root=/dev/???? and following it with rootfstype=ext4 (If this is what you formated it as). This is what I do here and things load faster:

root=/dev/sda1 rootfstype=ext4 rw rootwait console=ttyAMA0,115200 console=tty1 selinux=0 plymouth.enable=0 smsc95xx.turbo_mode=N dwc_otg.lpm_enable=0 kgdboc=ttyAMA0,115200 elevator=noop snd-bcm2835.enable_compat_alsa=0

You will have to manually move over the root partition to the usb stick or SSD. You can also create a swap file on the root partition (/swapfile). The swapfile I showed how to make above is a file not a partition.

Mate is supposed to be more intensive but on my tests here seems faster. Could be just me I guess.

I thought there was a link to a Mate image but I can not find it. I guess you will have to use buildarmoem as I believe the arminstaller might have some issues.

is only first part of a solution outlined in Arch wiki
https://wiki.archlinux.org/index.php/PulseAudio/Troubleshooting#Disabling_timer-based_scheduling_(0/4)

with timer-based scheduling disabled Pulseaudio does not manage audio buffer size
2 settings in Pulseaudio needed to set buffer size and number of fragments

Archwiki suggests editing /etc/pulse/daemon.conf
but i find it better to create custom configuration file ~/.config/pulse/daemon.conf and add the new settings there

default-fragments = X
default-fragment-size-msec = Y

with correct values calculated for X and Y

do not follow Arch and use pulseaudio -k as it will restart Pulseaudio in a different state to usual Manjaro startup
use systemctl --user restart pulseaudio

@nikgnomic

There are no buffer_size or fragment_size:

I found it. Have to run the command from the desktop instead via ssh.

I will play with it and report back. I have to say the sound sounds pretty good with out the other mods.

Thanks

I made the other mods and booted back and forth a few times and could not tell any difference. Only the default-fragment-size-msec changed from the default basically cutting in half. If any one wants to experiment and see if they notice any difference here are the values located near the bottom of the file /etc/pulse/daemon.conf

default-fragments = 4
default-fragment-size-msec = 12

I just rebooted after making the change.

there would be no ALSA parameters for Dummy Output virtual device
only for hardware devices

and hardware devices can sometimes work ok with defaults and no additional settings
defaults are in /etc/pulse/daemon.conf but commented out with ';'

Midori 9.0 should be in the aarch64 repo. So it should be able to install with:
sudo pacman -S midori

@petermc If you can't install Midori with the above mentioned command, please post the errors you get.

This topic was automatically closed 89 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by