When a userland application has an open file descriptor to /dev/pcmN, backed by an snd_uaudio(4) based device, trying to detach this device will hang the USB stack until the userland application is closed. Ultimately, this could lead to a complete stall of the USB stack. It would be expected that every child of snd_uaudio(4) just detach themselves, letting the userland die with EIO. How-To-Repeat: plug a snd_uaudio adapter open aumix(1) unplug the adapter
Responsible Changed From-To: freebsd-amd64->freebsd-multimedia reclassify.
Responsible Changed From-To: freebsd-multimedia->freebsd-usb This sounds potentially like a USB stack issue to me.
On Thursday 16 August 2012 14:54:00 gavin@freebsd.org wrote: > Synopsis: [snd_uaudio]: snd_uaudio(4) fails to detach when mixer is open > > Responsible-Changed-From-To: freebsd-multimedia->freebsd-usb > Responsible-Changed-By: gavin > Responsible-Changed-When: Thu Aug 16 12:53:15 UTC 2012 > Responsible-Changed-Why: > This sounds potentially like a USB stack issue to me. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=156726 This is not a USB stack problem, but a sound system issue. This is a known issue. --HPS
I ran into this problem in 13.0-RELEASE. In my case, suspend (via acpiconf) hangs on uaudio_detach_sub() ("Waiting for sound application to exit!") because an application is holding the mixer open. Can we re-open this issue for investigating a fix on the sound side, or should I open a new PR?
(In reply to Kevin Zheng from comment #4) Looks like this duplicates 194727. Could someone with permissions please add this to the duplicates list?