Bug 109431
Summary: | Crash at USB audio device removal | ||
---|---|---|---|
Product: | Drivers | Reporter: | Christian Casteyde (casteyde.christian) |
Component: | Sound(ALSA) | Assignee: | Jaroslav Kysela (perex) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | tiwai |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 4.3.3 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
Test fix patch
Patch to add timer refcount Fix patch #2 Revised fix patch #2 |
Description
Christian Casteyde
2015-12-15 17:47:12 UTC
Does the patch below fix the issue? Created attachment 199421 [details]
Test fix patch
I've managed to reproduce once with Kernel 4.4.0 without the patch, and I haven't managed to reproduce with the attached patch after 10 usb disconnect. So the patch seems to fix the problem. Vlc still do not shutdown correctly after disconnection, and when killing vlc after disconnect I sometimes get the following log in dmesg: ALSA: timer ffff8800a89d7200 is busy? but this may be correct. You're using dmix? This might be because we haven't do a proper refcount for timer device access. Could you try the patch below in addition? Meanwhile I submitted the USB-audio fix patch. It'll be likely included in the next pull request and will be backported eventually. Created attachment 199431 [details]
Patch to add timer refcount
I don't know if I'm really using dmix. I do not have ALSA config file (neither in /etc or in home), but I believed dmix was always on by default now. Anyway, with the refcount patch, I do not get the timer is busy warning, but vlc stays in zombie state forever now. After that, it is impossible to restart another one, and I cannot kill its parent either (kde4 init). Even reboot fails (/home and / not properly unmounted because "in use"), and reboot blocks at last until hard reset. It seems the process is definitively blocked, so it's worse as far as the user is concerned. OK, then could you tell the exact way how to reproduce the issue? Which application, how it is started, and how is it setup? It's pretty important to know how the audio device is accessed, either dmix, PA, direct hw, or whatever. OK, I'll describe the exact manipulation. I'm running Slackware 14.1 64bits, which doesn't use any fancy things such as dmix, etc. I have no /etc/asound.conf nor ~/.asoundrc file, so I'm using ALSA with default configuration. I'm running KDE, and playing sounds with VLC. The way to reproduce the problem is: 1) Plug in the USB audio transmitter. 2) Insert a CD in the drive. 3) Starts playing the CD with VLC (from the KDE notification popup menu). This starts vlc fiving it the CD device to read. 4) VLC starts playing the first title, on the laptop soundcard. 5) I switch the audio output to the USB card, using VLC menu "Audio | Audio device" to select the USB devince (default). VLC is configured to do "SRC resampling" with "Sinc function (best quality)" since ALSA do not resample correctly (cracks and cute sounds) to the USB card sample rate (48kHz whereas the CD is at 44kHz). 6) After playing the CD a while, I simply disconnect the USB drive, ***before*** closing VLC. 7) Then I try to close VLC: its windows is indeed closed, but VLC remains in the task list. 8) If I try to restart it, it doesn't since it's also configured as single instance (option "Interface|Use only one instance when started from file manager"). So I try to kill it with "killall -9 vlc". 9) VLC is then Zombie, with some KDE process as parent, but actually the kernel is already in a mess. Closing KDE session takes a while, reboot is endless: after a warning saying home and / partition are in use, the kernel freezes. It seems VLC is stucked while sending to the removed interface (in kernel space). Please note that sometimes, it works. But I can reproduce say 1 over 3 tries. Of course, closing VLC before removing the USB sticks works fine. Thanks, I could manage to reproduce it locally, too. Below is the fix patch. It works on my machine. VLC keeps spewing some error messages after disconnection, but it's a problem in the application side, basically. Created attachment 200711 [details]
Fix patch #2
Created attachment 200741 [details]
Revised fix patch #2
Has been fixed but not closed, so closing. |