Bug 194727 - uaudio device gets disconnected, and hangs usb until everything using /dev/mixer* is closed
Summary: uaudio device gets disconnected, and hangs usb until everything using /dev/mi...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: usb (show other bugs)
Version: CURRENT
Hardware: amd64 Any
: --- Affects Only Me
Assignee: freebsd-usb mailing list
URL:
Keywords:
: 239730 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-10-31 23:11 UTC by Tobias Berner
Modified: 2019-08-09 07:34 UTC (History)
8 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Berner 2014-10-31 23:11:43 UTC
Hi

I'm using a pair of KEF X300A speakers, which get recognized by the uaudio driver. 

Sporadically get: 
uaudio0: at uhub4, port 2, addr 3 (disconnected)
pcm0: unregister: channel pcm0:virtual:dsp0.vp0 busy (pid 2204)
pcm0: Waiting for sound application to exit!
pcm0: unregister: channel pcm0:virtual:dsp0.vp0 busy (pid 2204)
pcm0: Waiting for sound application to exit!
pcm0: unregister: channel pcm0:virtual:dsp0.vp0 busy (pid 2204)
pcm0: Waiting for sound application to exit!
[... -- closing/killing the concerning the application]
pcm0: Waiting for sound application to exit!
pcm0: unregister: mixer busy
pcm0: Waiting for sound application to exit!
pcm0: unregister: mixer busy
[repeat at infinitum]



The usb-stack seems to be completly hung at this point (usbconfig&friends hang) -- until I close everything else that has /dev/mixer* open. Then the device seems to reattach and gets usable again.
Comment 1 Hans Petter Selasky freebsd_committer 2014-11-01 07:48:47 UTC
Hi,

This is correct behaviour from the kernel. We need to trace down these apps and make them disconnect the mixer device when the USB AUDIO device detaches.

Possibly same with pulseaudio.

Do you know which mixer APP this is? XFCE?

--HPS
Comment 2 Tobias Berner 2014-11-01 10:28:58 UTC
Hi

2204 was mplayer. 
The one I had to kill to get the stack unhung was kdeinit. So I guess it is a problem in kde.

mfg Tobias
Comment 3 Cory Smelosky 2015-12-16 04:50:49 UTC
Is this expected behaviour when entering sleep, however?  Apps have stopped but not freed the pcm device.

Looks like i'll be running fuser before acpiconf. ;)

Would it make more sense to _eventually_ give up and and send EPIPE or similar?  \
Comment 4 Hans Petter Selasky freebsd_committer 2015-12-16 15:56:46 UTC
Hi,

Yes, mixer apps must close their handles when they detect the device is gone!

--HPS
Comment 5 Ivan 2018-06-22 17:49:57 UTC
This is illogical. USB supports hot plug, so kernel must handle it without stucking. I use audio with KVM b/w Linux. Windows and FreeBSD and I can't even kill mixer as entire USB waits indefinitely.

My observations with FF playing youtube video
1. Windows - active playback resumes after FF restart
2. Linux - active playback resumes after FF restart
3. FreeBSD needs reset button.
Comment 6 Hans Petter Selasky freebsd_committer 2018-06-22 20:50:42 UTC
Hi,

Applications must close their handles upon detecting failures, like detach. Else device numbers will be used up pretty quickly.

This is a known issue.

One solution is perhaps to use audio/virtual_oss, which proxy access to /dev/dsp and possibly in the future /dev/mixer aswell, so that these FreeBSD specific artifacts are hidden.

--HPS
Comment 7 Ivan 2018-06-23 20:30:26 UTC
Interesting  solution indeed!
However, looks like I'm out of luck as several processes attached to mixer.
abishai@darkstar:~ % fstat /dev/dsp* /dev/mixer* 
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W NAME
abishai  kmix        3325   13 /dev        198 crw-rw-rw-  mixer1 rw  /dev/mixer1
abishai  kmix        3325   14 /dev        198 crw-rw-rw-  mixer1 rw  /dev/mixer1
abishai  kdeinit5    3277 2188 /dev        198 crw-rw-rw-  mixer1 rw  /dev/mixer1
abishai  kdeinit5    3277 2189 /dev        198 crw-rw-rw-  mixer1 rw  /dev/mixer1
Comment 8 Hans Petter Selasky freebsd_committer 2018-06-24 08:10:09 UTC
kmix is a process in KDE5. Why not just fix it?

--HPS
Comment 9 Hans Petter Selasky freebsd_committer 2018-06-24 08:18:19 UTC
One solution here is that the sound driver waits a bit and then kills the process in question with SIGPIPE.
Comment 10 Hans Petter Selasky freebsd_committer 2018-06-24 08:30:42 UTC
I'm not sure what will happen if kmix is killed. Will it be restarted somehow? I guess this needs a better fix.
Comment 11 Andriy Gapon freebsd_committer 2018-06-24 09:12:58 UTC
(In reply to Hans Petter Selasky from comment #9)
I think that in FreeBSD we have an ability to revoke a file descriptor.
Can we use it to disassociate anything that userland has open from the device that we want to let go?
Comment 12 Hans Petter Selasky freebsd_committer 2018-06-24 09:28:08 UTC
The problem is that the application, in this case a desktop application will stop working, because it will never detect that the mixer device is gone.

--HPS
Comment 13 Ivan 2018-06-24 18:26:07 UTC
(In reply to Hans Petter Selasky from comment #10)
I've made a simple script that kills all processes that hold descriptor, they are just quit, so I need to restart them. I don't think this is kmix only issue, users of other DE probably have another mixer.

I can see that Linux has more general purpose solution Maybe, pulseaudio handles this like OSS proxy you've suggested ? Then, proxy solution is the only right, as this is seamless for userland.
Comment 14 benibilme 2018-10-27 19:07:32 UTC
Hello,

I have the very same issue. I am a newbie on freebsd. I installed iFreeBSD fujitsu 11.2-RELEASE with kde5 to my fujitsu 920 minipc. I have currently no sound. Since I am trying to configure this machine as my primary desktop machine this is a show stopper for me. Is there a way to circumvent this issue.. 

pcm2: Waiting for sound application to exit!
pcm2: unregister: mixer busy
pcm2: Waiting for sound application to exit!
pcm2: unregister: mixer busy
pcm2: Waiting for sound application to exit!
pcm2: unregister: mixer busy
pcm2: Waiting for sound application to exit!
pcm2: unregister: mixer busy
pcm2: Waiting for sound application to exit!
pcm2: unregister: mixer busy
pcm2: Waiting for sound application to exit!
pcm2: unregister: mixer busy
pcm2: Waiting for sound application to exit!
pcm2: unregister: mixer busy
pcm2: Waiting for sound application to exit!
pcm2: detached
pcm2: <USB audio> on uaudio0
pcm0: <Intel Haswell (HDMI/DP 8ch)> at nid 3 on hdaa0
pcm1: <Realtek ALC671 (Rear Analog)> at nid 33 and 24 on hdaa1
pcm2: <USB audio> on uaudio0


root@fujitsu:~ # fstat /dev/dsp* /dev/mixer*
USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W NAME
toktay   pulseaudio  1117   20 /dev         62 crw-rw-rw-  mixer1 rw  /dev/mixer1
toktay   pulseaudio  1117   30 /dev         62 crw-rw-rw-  mixer1 rw  /dev/mixer1
toktay   pulseaudio  1117   40 /dev         97 crw-rw-rw-  mixer2 rw  /dev/mixer2
toktay   kmix        1113   13 /dev         62 crw-rw-rw-  mixer1 rw  /dev/mixer1
toktay   kmix        1113   14 /dev         62 crw-rw-rw-  mixer1 rw  /dev/mixer1
toktay   kmix        1113   15 /dev         97 crw-rw-rw-  mixer2 rw  /dev/mixer2
toktay   kdeinit5    1049 2564 /dev         62 crw-rw-rw-  mixer1 rw  /dev/mixer1
toktay   kdeinit5    1049 2608 /dev         62 crw-rw-rw-  mixer1 rw  /dev/mixer1
toktay   kdeinit5    1049 2610 /dev         97 crw-rw-rw-  mixer2 rw  /dev/mixer2
Comment 15 Theron Tarigo 2019-01-16 06:52:08 UTC
(In reply to Hans Petter Selasky from comment #1)
Many applications fail to disconnect from mixer when required.  How is it "correct behaviour from the kernel" for the kernel to only behave correctly (keep USB and suspend working) when applications also behave correctly?  These audio playback applications are not normally granted permission to obstruct kernel facilities.

The virtual_oss behaves very well indeed, but must the kernel remain so fragile that virtual_oss is the only application I should grant permission to access /dev/dsp ?

(In reply to Hans Petter Selasky from comment #9)
"One solution here is that the sound driver waits a bit and then kills the process in question with SIGPIPE."
This is much more acceptable than putting the system into an unrecoverable state when attempting to sleep (compare the established behavior of killing any processes which refuse to quit during full shutdown).
Comment 16 Matthias Oestreicher 2019-04-25 17:57:14 UTC
I've had the same issue since FreeBSD 11.2-RELEASE with if_uaudio.ko and audio/cmus. Audio device is a 9 year old HRT MusicStreamer II+.
When I was on FreeBSD 11.2, the system would suspend, but USB hung up when resumed.
In FreeBSD 12.0-RELEASE, the stalled usb drivers will stall before suspending has finished.
I tried to disconnecting the audio device when USB stalls, but that doesn't help
Only solution is to ssh into the machine and kill cmus (no -9 needed) and usb keyboard and mouse, etc will come back to life and suspend/resume will finish.
/dev/ttyv0 is flooded with "Waiting for mixer..." and "Waiting for sound application to exit" 
This is on USB 2.0 native on Intel Broadwell CPU.

I already posted that on the forums in november 2018:
https://forums.freebsd.org/threads/weird-xhci-crash-freeze-after-resume-from-suspend.68277/

I wonder if this is specific to a Intel processor/chipset generation, as almost every new generation of Intel processors/chipsets comes with a new set of bugs. Though that's just a guess.

I have another computer with a different audio device using if_uaudio.ko, a Asus Impressario BluRayDrive with Xonar audio. This one works fine with suspend/resume on FreeBSD 12.0-RELEASE.
I'll move the audio-devices around and post back, maybe that'll give a hint what's the cause.

-Matthias
Comment 17 Greg V 2019-07-24 22:32:40 UTC
I'm seeing a similar-but-not-really issue on my aarch64 box (MACCHIATObin). After watching YouTube for some minutes, with an old ASUS Xonar uaudio0 (recognized as "C-Media Electronics Inc. USB Advanced Audio Device"), suddenly for a couple seconds the audio starts crackling and muting, and then stops, and in a few seconds USB input (!) stops working. Specifically USB mouse and keyboard. USB Ethernet keeps working fine. I can even start playing music over SSH, headphones are silent but the progress bar keeps going. I can unplug the audio card and it detaches fine. But USB input is dead, even after `usbconfig reset` there are no events on libinput, no input on the vt console either.
Comment 18 Greg V 2019-08-04 13:24:55 UTC
(In reply to Greg V from comment #17)
update: a different USB soundcard seems fine so far
Comment 19 Hans Petter Selasky freebsd_committer 2019-08-09 07:34:30 UTC
*** Bug 239730 has been marked as a duplicate of this bug. ***