On Wed, 14 Jun 2006, Takashi Iwai wrote: > > As another individual pointed out a few months ago, there are some > > other problems with snd-usb-audio similar to those described above. > > If a certain usb audio device has open file handles and is > > disconnected or the system is suspended, > > snd_usb_audio_disconnect()->snd_card_free() will block in the khubd > > context while ALSA waits for the file handles to be closed, preventing > > khubd from doing anything else useful like processing probe requests. > > Using snd_card_free_in_thread() can be just as bad as it uses > > schedule_work() and blocks one of the "events" threads. A hang in > > either context can cause problems for a resume-from-RAM operation. > > Hm, this has to be fixed. Just skipping the wait for file close will > solve the problem? Skipping the wait means calling snd_card_free() in last fops->release(), but as I mentioned, the card slot is still in use in this time. So it is not guaranteed that the reconnected devices will have same IDs. I think that best way is to fix applications to handle such situations as fast as possible and eventually add an event mechanism (if missing) to notify applications as fast as possible that device is no more available. BTW: It's good that the USB layer handles susped/resume in midlevel. Jaroslav ----- Jaroslav Kysela <perex@xxxxxxx> Linux Kernel Sound Maintainer ALSA Project, SUSE Labs _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
