On Mon, 16 Oct 2017 04:26:42 +0200, Kuninori Morimoto wrote: > > > Hi Takashi > > > > I could confirm this by printing who's stop was called by local quick hack. > > > > > > Maybe timing reason, if kernel has Oops for some reasons, > > > then, both BE/FE snd_pcm_stop() are called. > > > If no Oops, BE snd_pcm_stop() only called. > > > > Any pending delayed work (like rtd->delayed_work)? > > This is flushed at soc_cleanup_card_resources(), but it's called at > > card removal, thus it's too late for the hot-removal of the > > component. > > Current my dirver used delayed_work, but we can control it > by snd_soc_runtime_ignore_pmdown_time(); > I think my driver now doesn't use delayed_work. > > But there is still issue. > I don't know detail, but it seems > snd_pcm_dev_disconnect() and snd_pcm_relase() are called > it the same time, both are calling snd_pcm_stop(). > > Then, snd_pcm_relase() side will calls > snd_pcm_detach_substream() and snd_pcm_dev_disconnect() side will die. This must be also specific to DPCM. Something is really wrong there. Basically snd_pcm_dev_disconnect() and snd_pcm_release() can't race since both are protected via pcm->open_mutex. snd_pcm_stop() calls are protected even more with substream lock. > Mark's suggestion (= hiding BE) can solve this ? Some of the issues might be addressed, yes, but I'm skeptical whether it covers all. The BE needs proper locking and refcounting that is coupled with the FE, I suppose. Takashi _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
