Bug 220949 - When the only USB soundcard is disconnected, defunct /dev/dsp0 is left, kernel warnings, programs hang
Summary: When the only USB soundcard is disconnected, defunct /dev/dsp0 is left, kerne...
Status: Closed DUPLICATE of bug 194727
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: 11.0-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-usb (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-07-23 16:32 UTC by Yuri Victorovich
Modified: 2024-04-15 00:18 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri Victorovich freebsd_committer freebsd_triage 2017-07-23 16:32:39 UTC
I have a USB webcam that is also a soundcard with only a microphone, and no speaker. When there are no other audio devices, disconnecting this USB webcam causes system dysfunction.

There are a lot of repeating messages in log:
> Jul 23 09:14:21 yv kernel: pcm0: unregister: mixer busy
> Jul 23 09:14:21 yv kernel: pcm0: Waiting for sound application to exit!
> Jul 23 09:14:23 yv kernel: pcm0: unregister: mixer busy
> Jul 23 09:14:23 yv kernel: pcm0: Waiting for sound application to exit!

Programs that have this device open hanged and became unkillable with kill -9.

'kldunload snd_uaudio.ko' also hangs in unkillable state.

USB is hot-pluggable. Device is supposed to disappear and reappear without any long-term effects.

IMO, /dev/dspN should disappear when device is removed. Programs that have it opened should behave gracefully. They should only get errors from it and not hang.

USB webcam: HD Pro Webcam C920 (vendor 0x046d, product 0x6860)
Comment 1 Hans Petter Selasky freebsd_committer freebsd_triage 2017-07-23 19:38:25 UTC
This is a known issue. The solution is not just straight forward, due to mmap() use. See also.

https://reviews.freebsd.org/D11140

--HPS
Comment 2 commit-hook freebsd_committer freebsd_triage 2024-03-31 14:16:59 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/src/commit/?id=9eff58c6d52b66eb8abe7f724dabcd804a566df4

commit 9eff58c6d52b66eb8abe7f724dabcd804a566df4
Author:     Christos Margiolis <christos@FreeBSD.org>
AuthorDate: 2024-03-31 14:13:43 +0000
Commit:     Christos Margiolis <christos@FreeBSD.org>
CommitDate: 2024-03-31 14:13:43 +0000

    sound: Implement asynchronous device detach

    Hot-unplugging a sound device, such as a USB sound card, whilst being
    consumed by an application, results in an infinite loop until either the
    application closes the device's file descriptor, or the channel
    automatically times out after hw.snd.timeout seconds. In the case of a
    detach however, the timeout approach is still not ideal, since we want
    all resources to be released immediatelly, without waiting for N seconds
    until we can use the bus again.

    The timeout mechanism works by calling chn_sleep() in chn_read() and
    chn_write() (see pcm/channel.c) in order to send the thread to sleep,
    using cv_timedwait_sig(). Since chn_sleep() sets the CHN_F_SLEEPING flag
    while waiting for cv_timedwait_sig() to return, we can test this flag in
    pcm_unregister() (called during detach) and wakeup the sleeping
    thread(s) to immediately kill the channel(s) being consumed.

    Sponsored by:   The FreeBSD Foundation
    MFC after:      2 months
    PR:             194727, 278055, 202275, 220949, 272286
    Reviewed by:    dev_submerge.ch, markj
    Differential Revision:  https://reviews.freebsd.org/D43545

 share/man/man4/snd_uaudio.4 | 11 +----------
 sys/dev/sound/pcm/dsp.c     |  2 +-
 sys/dev/sound/pcm/mixer.c   | 11 -----------
 sys/dev/sound/pcm/sound.c   | 24 ++++++++++--------------
 sys/dev/sound/usb/uaudio.c  | 13 +++----------
 5 files changed, 15 insertions(+), 46 deletions(-)
Comment 3 Christos Margiolis freebsd_committer freebsd_triage 2024-04-14 21:06:01 UTC
Fixed as of 44e128fe9d92c1a544b801cb56e907a66ef34691
Comment 4 Christos Margiolis freebsd_committer freebsd_triage 2024-04-15 00:18:24 UTC

*** This bug has been marked as a duplicate of bug 194727 ***