On Wed, 09 Mar 2022 10:02:13 +0100, Tvrtko Ursulin wrote: > > > On 09/03/2022 08:39, Kai Vehmanen wrote: > > Hi, > > > > On Wed, 9 Mar 2022, Tvrtko Ursulin wrote: > > > >>> - /* 60s timeout */ > >> > >> Where does this 60s come from and why is the fix to work around > >> DEFAULT_HUNG_TASK_TIMEOUT in a hacky way deemed okay? For instance would > >> limiting the wait here to whatever the kconfig is set to be an option? > > > > this was discussed in > > https://lists.freedesktop.org/archives/intel-gfx/2022-February/290821.html > > ... and that thread concluded it's cleaner to split the wait than try > > to figure out hung-task configuration from middle of audio driver. > > > > The 60sec timeout comes from 2019 patch "ALSA: hda: Extend i915 component > > bind timeout" to fix an issue reported by Paul Menzel (cc'ed). > > > > This patch keeps the timeout intact. > > I did not spot discussion touching on the point I raised. > > How about not fight the hung task detector but mark your wait context > as "I really know what I'm doing - not stuck trust me". The question is how often this problem hits. Basically it's a very corner case, and I even think we may leave as is; that's a matter of configuration, and lowering such a bar should expect some side-effect. OTOH, if the problem happens in many cases, it's beneficial to fix in the core part, indeed. > Maybe using > wait_for_completion_killable_timeout would do it since > snd_hdac_i915_init is allowed to fail with an error already? It makes it killable -- which is a complete behavior change. Takashi
