Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 30 Jul 2021 00:57:42 +0000
From:      bugzilla-noreply@freebsd.org
To:        gnome@FreeBSD.org
Subject:   [Bug 194727] uaudio device gets disconnected, and hangs usb until everything using /dev/mixer* is closed
Message-ID:  <bug-194727-6497-HGLcIXsMo2@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-194727-6497@https.bugs.freebsd.org/bugzilla/>
References:  <bug-194727-6497@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194727

--- Comment #57 from Theron Tarigo <theron.tarigo@gmail.com> ---
I started hacking on this today, and I see two options for fixing the kernel
side:

1. allow pcm_unregister to forcibly close and destroy the device file.  The
kernel already does something like this for block storage devices removed w=
hile
in use.  Applications may respond badly but it's better than what we have n=
ow,
and pulseaudio and virtual_oss should already handle this.

2. unhook uaudio instance destruction from device detach.  This allows the =
pcm
device to persist independently of the usb device, ready to clean up when it
can.

(2) seems the better option, as it provides the opportunity to reattach pcm
device when the USB device is reattached, or after resume from suspend.=20
However I'm unsure how to proceed with this option.  Are there any other
drivers capable of persisting independently of their bus devices' detaching=
 to
use as an example?

As for the kernel resource "leak": I'm well aware option (2) leads right in=
to
this.  However unless implemented incorrectly these resources are still tie=
d to
a user process: recovery of the exhausted resource by action taken from wit=
hin
userspace (killing the offending and leaky application, as we already do for
low memory, too many tabs playing audio, etc.) remains sufficient.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-194727-6497-HGLcIXsMo2>