forcing off the computer – endlessly waiting for sound application to exit at sleep/suspend time

grahamperrin

Aspiring Daemon

Reaction score: 189
Messages: 643

It's frequently necessary to force off a computer (HP EliteBook 8570p, sometimes docked) when an attempt to suspend fails, with these messages from kernel:


Code:
pcm3: unregister: mixer busy
pcm3: Waiting for sound application to exit!


I subscribe to this bug:


– however the circumstances puzzle me, because it's sometimes necessary to force off the computer after:
  • not knowingly listening, or speaking, to anything (not knowingly using any audio device)
  • not knowingly disconnecting any device.
For me, this is by far the worst aspect of using FreeBSD. If I can't reliably sleep the computer without forcing off the power – effectively losing what's in my L2ARC, and so on:
  • it's not a stable system.
Through commands such as this:

zcat /var/log/messages.3.bz2 | grep -A 1 "Waiting for sound application to exit!"

– I identified a period between two boots when, if I'm not mistaken, the symptoms occurred without an attempt to suspend. Beginning at line 563 of the attached file.

Re: <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194727#c53> a few weeks ago I created a one-line file:

/etc/syslog.d/bug194727.conf
Code:
:msg, contains, "Waiting for sound application to exit!" kern.* |while read _ ; do pkill pulseaudio || : ; done

Still, sometimes, it's necessary to press and hold the power button.

Might I have more luck with the pre-suspend script at the foot of this 2020 article?

USB audio devices on FreeBSD

Where should I save the file, how should I name it?
 

Attachments

  • mixer busy at line 563.txt
    350.9 KB · Views: 9
OP
grahamperrin

grahamperrin

Aspiring Daemon

Reaction score: 189
Messages: 643

For reference, following correspondence with David Schlachter (author of the article mentioned above):

Code:
root@mowa219-gjp4-8570p:~ # cat /dev/sndstat
Installed devices:
pcm0: <ATI R6xx (HDMI)> (play)
pcm1: <IDT 92HD81B1X (Analog 2.0+HP/2.0)> (play/rec) default
pcm2: <IDT 92HD81B1X (Analog)> (play/rec)
pcm3: <USB audio> (rec)
No devices installed from userspace.
root@mowa219-gjp4-8570p:~ # sysctl hw.snd.default_unit
hw.snd.default_unit: 1
root@mowa219-gjp4-8570p:~ # fstat | grep dsp
grahampe firefox     6470   59 /dev        178 crw-rw-rw-  dsp1.0  w
grahampe VirtualBoxVM  6163   36 /dev        558 crw-rw-rw-  dsp2.0  w
grahampe VirtualBoxVM  6333   32 /dev        174 crw-rw-rw-  dsp0.0  w
root@mowa219-gjp4-8570p:~ # cat /usr/local/sbin/suspend.sh
# Close up the USB sound card before suspend
sysctl hw.snd.default_unit=1

# Close any programs still using the sound card
while fstat | grep dsp1 2>&1; do
   fstat | grep dsp1 | cut -w -f 3 | while read pid;
      do kill -15 "$pid"
   done
done
while [ "$(ls -l /dev | grep -c dsp1)" -gt 1 ]; do
   sleep 1
done
/usr/sbin/acpiconf -s3
root@mowa219-gjp4-8570p:~ # cat /etc/devd/acpi_lid_close.conf
# devd/acpi_lid_close.conf
notify 20 {
    match "system"    "ACPI";
    match "subsystem" "Lid";
    match "notify"    "0x00";
    action "/usr/local/sbin/suspend.sh";
};
root@mowa219-gjp4-8570p:~ # sysctl hw.acpi.lid_switch_state
hw.acpi.lid_switch_state: NONE
root@mowa219-gjp4-8570p:~ #

I don't know why VirtualBoxVM was using those two devices, it's probably negligible. I always manually close all VirtualBox stuff before attempting to sleep the computer (because the data is stored on ZFS on USB; need to export the pool before sleeping).

pcm1: <IDT 92HD81B1X (Analog 2.0+HP/2.0)> (play/rec) is what's normally used …
 
OP
grahamperrin

grahamperrin

Aspiring Daemon

Reaction score: 189
Messages: 643

Success!

With playback in Firefox before closing the lid, I closed the lid, let the computer sleep for a few seconds, raised the lid, pressed the power button to wake the computer.

Result: nothing more than a crashed tab, which is fine.

1621295714008.png


I restored the tab, playback resumed.
 
OP
grahamperrin

grahamperrin

Aspiring Daemon

Reaction score: 189
Messages: 643

Sadly, three days ago:

1621684755761.png


I guess I could make my /usr/local/sbin/suspend.sh more complex but honestly, I prefer to:
  • avoid using USB devices with FreeBSD.
 
OP
grahamperrin

grahamperrin

Aspiring Daemon

Reaction score: 189
Messages: 643

In this case, the USB headset that was previously at pcm3 and pcm4 was no longer connected.

When connected (to the previously used port, left hand side of HP EliteBook 8570p): FreeBSD failed to detect the connection.

Code:
% fstat | grep dsp
% tail -f -n 0 /var/log/messages
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:39:23 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
^C
% cat /dev/sndstat
Installed devices:
pcm0: <ATI R6xx (HDMI)> (play)
pcm1: <IDT 92HD81B1X (Analog 2.0+HP/2.0)> (play/rec) default
pcm2: <IDT 92HD81B1X (Analog)> (play/rec)
pcm3: <USB audio> (rec)
pcm4: <USB audio> (play/rec)
No devices installed from userspace.
% time lsusb | sort
load: 0.59  cmd: sort 7881 [piperd] 38.65r 0.00u 0.00s 0% 2128k
mi_switch+0xc1 sleepq_catch_signals+0x2e6 sleepq_wait_sig+0x9 _sleep+0x1be pipe_read+0x3d6 dofileread+0x81 sys_read+0xbc amd64_syscall+0x10c fast_syscall_common+0xf8
^C% sudo zpool export Transcend
grahamperrin's password:
cannot unmount '/Volumes/t500/VirtualBox': pool or dataset is busy
% pkill gvfsd-trash
% sudo zpool export Transcend
% sudo zpool offline copperbowl gpt/cache-copperbowl
% time lsusb | sort
^Ctail -f -n 0 /var/log/messages
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:44:53 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: unregister: mixer busy
May 28 12:45:00 mowa219-gjp4-8570p kernel: pcm4: Waiting for sound application to exit!
^C
%

Worked around by restarting the OS :-(
 
OP
grahamperrin

grahamperrin

Aspiring Daemon

Reaction score: 189
Messages: 643

After a few more incidents, I began toying with running the script manually.

Run in this way, it does not sleep the computer, but I hope that it will identify processes that must end before sleep can be attempted.

Re: the code block below
  • yesterday I chose to quit Firefox entirely before sleep
  • now (foot of the block) I see nothing to prevent sleep
– wish me luck …

Code:
# /usr/local/sbin/suspend.sh
hw.snd.default_unit: 1 -> 1
grahampe firefox     9658   92 /dev        681 crw-rw-rw-  dsp1.1  w
^C
# /usr/local/sbin/suspend.sh
hw.snd.default_unit: 1 -> 1
^C
# exit
root@mowa219-gjp4-8570p:~ # sh
# /usr/local/sbin/suspend.sh
hw.snd.default_unit: 1 -> 1
load: 0.82  cmd: sleep 12412 [nanslp] 0.38r 0.00u 0.00s 0% 1872k
mi_switch+0xc1 sleepq_catch_signals+0x2e6 sleepq_timedwait_sig+0x12 _sleep+0x199 kern_clock_nanosleep+0x1e1 sys_nanosleep+0x3b amd64_syscall+0x10c fast_syscall_common+0xf8
sleep: about 0 second(s) left out of the original 1
^C
# zpool offline copperbowl gpt/cache-copperbowl
# slowcat /usr/local/sbin/suspend.sh
# Close up the USB sound card before suspend
sysctl hw.snd.default_unit=1

# Close any programs still using the sound card
while fstat | grep dsp 2>&1; do
   fstat | grep dsp | cut -w -f 3 | while read pid;
      do kill -15 "$pid"
   done
done
while [ "$(ls -l /dev | grep -c dsp)" -gt 1 ]; do
   sleep 1
done
/usr/sbin/acpiconf -s3
# acpiconf -s 3
 
OP
grahamperrin

grahamperrin

Aspiring Daemon

Reaction score: 189
Messages: 643

No problem yesterday morning (the script found nothing to kill).

Yesterday afternoon, after the script found nothing to kill I attempted to sleep the computer. For the umpteenth time I found myself endlessly waiting for sound application to exit and had to press-and-hold the power button.

Is there a reliable way of telling whether this sound application problem will occur?
 

xchris

Member

Reaction score: 16
Messages: 87

I have the same issue on desktop , when I use the the webcam -eg with firefox- the "Waiting for sound application to exit!" spams the logs... -and the system can't hibernate
but in my case I m just unpluging the camera/killing the firefox ...
 

Alexander88207

Aspiring Daemon

Reaction score: 294
Messages: 501

The application that blocks your shutdown is pulseaudio or an application that uses Pulseaudio.

I do use the Cinnamon eviroment that uses also pulseaudio but i never had that Problem. Maybe because i do close app applications before i shutdown.

For workaround you can do killall pulseaudio before shutdown.
 
OP
grahamperrin

grahamperrin

Aspiring Daemon

Reaction score: 189
Messages: 643

Thanks,

… For workaround you can do killall pulseaudio before shutdown.

On one occasion, every kill of pulseaudio (using htop) was swifly followed by a re-run of pulseaudio.

When (from within the script) fstat | grep dsp shows nothing, and pulseaudio is automatically re-run, how can I reliably tell which processes must be killed?
 

Vull

Well-Known Member

Reaction score: 149
Messages: 340

... how can I reliably tell which processes must be killed?
Compare top output from before and after installing pulseaudio, maybe. I really should take the time and try to do this myself next re-install.

Haven't had any system hangs, yet(!), but pulseaudio behaves badly for me too on FreeBSD, and almost always leaves some kind of error message as it fights to stay alive during system shutdowns or restarts. Pulseaudio... can't live with it, can't live without it...
 
Top