sound: Remove chn_timeout check from chn_init()
This check is not related to channel initializion, but is also
unnecessary, since sysctl_hw_snd_timeout() takes care of checking if
chn_timeout is within bounds.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44992
sound: Move pcm_chnref() and pcm_chnrelease() to pcm/channel.c
Improve code layering. These are channel functions, and so they do not
belong in pcm/sound.c.
While here, assert in chn_ref() that new refcount won't be negative.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44985
sound: Retire unit.*
The unit.* code is largely obsolete and imposes limits that are no
longer needed nowadays.
- Capping the maximum allowed soundcards in a given machine. By default,
the limit is 512 (snd_max_u() in unit.c), and the maximum possible is
2048 (SND_UNIT_UMAX in unit.h). It can also be tuned through the
hw.snd.maxunit loader(8) tunable. Even though these limits are large
enough that they should never cause problems, there is no need for
this limit to exist in the first place.
- Capping the available device/channel types. By default, this is 32
(snd_max_d() in unit.c). However, these types are pre-defined in
pcm/sound.h (see SND_DEV_*), so the cap is unnecessary when we know
that their number is constant.
- Capping the number of channels per-device. By default, the limit 1024
(snd_max_c() in unit.c). This is probably the most problematic of the
limits mentioned, because this limit can never be reached, as the
maximum is hard-capped at either hw.snd.maxautovchans (16 by default),
[24 lines not shown]
sound: Fix panic caused by sleeping-channel destruction during asynchronous detach
Currently we are force-destroying all channels unconditionally in
pcm_killchan(). However, since asynchronous audio device detach is
possible as of 44e128fe9d92, if we do not check whether the channel is
sleeping or not and forcefully kill it, we will get a panic from
cv_timedwait_sig() (called from chn_sleep()), because it will try to use
a freed lock/cv.
Modify pcm_killchan() (renamed to pcm_killchans() since that's a more
appropriate name now) to loop through the channel list and destroy only
the channels that are awake, otherwise wake up the sleeping thread and
try again. This loop is repeated until all channels are awakened and
destroyed.
To reduce code duplication, implement chn_shutdown() which wakes up the
channel and sets CHN_F_DEAD, and use it in pcm_unregister() and
pcm_killchans().
[6 lines not shown]
sound: Fix NULL dereference in dsp_clone() and mixer_clone()
If we only have a single soundcard attached and we detach it right
before entering [dsp|mixer]_clone(), there is a chance pcm_unregister()
will have returned already, meaning it will have set snd_unit to -1, and
thus devclass_get_softc() will return NULL here.
While here, 1) move the calls to dsp_destroy_dev() and mixer_uninit()
below the point where we unset SD_F_REGISTERED, and 2) follow what
mixer_clone() does and make sure we don't use a NULL d->dsp_dev in
dsp_clone().
Reported by: KASAN
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44924
sound: Add missing space in dev.pcm.X.mode description
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D44990
sound: Wrap dsp_clone() and mixer_clone() with bus_topo_lock()
Make sure that the softc isn't freed in between the checks.
Sponsored by: The FreeBSD Foundation
MFC after; 1 day
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44991
sound: Merge pcm_chn_destroy() and chn_kill()
pcm_chn_destroy() acts like a wrapper around chn_kill(), and
additionally calls a few more functions that should in fact be part of
chn_kill()'s logic. Merge pcm_chn_destroy()'s functionality in
chn_kill() to improve readability, as well as code layering.
While here, convert chn_kill() to void as it currently always returns 0.
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Reviewed by: markj
Differential Revision: https://reviews.freebsd.org/D44984
sound: Assert that we do not enter chn_sleep() with CHN_F_SLEEPING
Sponsored by: The FreeBSD Foundation
MFC after: 1 day
Reviewed by: markj, emaste
Differential Revision: https://reviews.freebsd.org/D44959
rtld snprintf: do not erronously skip a char at the buffer boundary
Reviewed by: emaste, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D44987
www/qt5-webengine: Bump PORTREVISION after fa01e117e24f
The port archivers/snappy was updated to version 1.2.0 via fa01e117e24f
but there was no PORTREVISION bump afterwards for qt5-webengine, which
uses archivers/snappy.
This led to the following runtime error as soon as consumers (e.g.
x11-fm/konqueror) using qt5-webengine were started:
ld-elf.so.1: /usr/local/lib/qt5/libQt5WebEngineCore.so.5: Undefined symbol "_ZN6snappy11RawCompressEPKcmPcPm"
Remedy the issue by bumping PORTREVISION to force a rebuild against the
new version of archivers/snappy.
PR: 278633
Reported by: Graham Perrin
MFH: 2024Q2
With hat: kde
sync.8: Document that the "sync dance" is not a thing
People still believe that it is essential to run sync(8) a couple of
times before a reboot/halt. Document that this has not been necessary
for a long time now.
Reviewed by: imp, bcr, Pau Amma <pauamma at gundo.com>
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D33233
(cherry picked from commit 177ba183076bd6fe6b29b1d657b954cca256506b)
sync.8: Document that the "sync dance" is not a thing
People still believe that it is essential to run sync(8) a couple of
times before a reboot/halt. Document that this has not been necessary
for a long time now.
Reviewed by: imp, bcr, Pau Amma <pauamma at gundo.com>
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D33233
(cherry picked from commit 177ba183076bd6fe6b29b1d657b954cca256506b)
gettimeofday.2: Do mention improbable future removal
As kib@ noted:
> Obviously gettimeofday(2) is not going to be removed
> even in the far future.
Reported by: kib
Fixes: 4395d3ced5cf Document that gettimeofday() is obsolescent
MFC after: 3 days
