At Wed, 14 Jun 2006 14:19:14 +0200, I wrote: > > At Wed, 14 Jun 2006 13:37:14 +0200 (CEST), > Jaroslav Kysela wrote: > > > > 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(), > > No, snd_card_free() is called in disconnect callback. I was too desnse. You meant "a part of jobs of snd_card_free()" is going to be executed in the last release? Anyway, re-reading the quote above, it sounds more like a problem happening only via suspend. Then, this might be solved automatically if the proper suspend/resume is implemented on usb-audio driver. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/alsa-devel
