From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751691AbdAYPON (ORCPT ); Wed, 25 Jan 2017 10:14:13 -0500 Received: from mx2.suse.de ([195.135.220.15]:45439 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750772AbdAYPOM (ORCPT ); Wed, 25 Jan 2017 10:14:12 -0500 Date: Wed, 25 Jan 2017 15:54:37 +0100 Message-ID: From: Takashi Iwai To: "Vlastimil Babka" Cc: "Jaroslav Kysela" , , "LKML" Subject: Re: workqueue lockup due to process_unsol_events stuck in azx_rirb_get_response In-Reply-To: <855fe8a9-4167-e193-d3d1-45e9d39630b1@suse.cz> References: <855fe8a9-4167-e193-d3d1-45e9d39630b1@suse.cz> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/25.1 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 25 Jan 2017 13:28:11 +0100, Vlastimil Babka wrote: > > Hi, > > my desktop randomly experiences workqueue lockups on boot with > openSUSE Tumbleweed kernels 4.9.x, installed around > Christmas. Previously I had a (badly maintained) Gentoo installation > with 4.4 IIRC, so I can't say if the kernel has regressed, or the > major userspace changes exposed different timing of stuff. If the lockup can be reproduced easily, could you check whether the old kernel shows the issue? I don't remember of any big changes in ca0132 driver in 4.x kernels. It'd be helpful even just checking an openSUSE Leap 42.1 or 42.2 kernel. > This is how the workqueue lockup looks like: (snip) > kernel: [] dspio_read+0x51/0x70 [snd_hda_codec_ca0132] > kernel: [] ca0132_process_dsp_response+0x46/0x160 > [snd_hda_codec_ca0132] > kernel: [] call_jack_callback.isra.1+0x25/0xa0 [snd_hda_codec] > kernel: [] snd_hda_jack_unsol_event+0x66/0x80 [snd_hda_codec] > kernel: [] hda_codec_unsol_event+0x17/0x20 [snd_hda_codec] > kernel: [] process_unsol_events+0x63/0x70 [snd_hda_core] This is the code path that runs when the codec chip (CA0132) receives an unsolicited event with a specific tag (0x16). It means the DSP communication going. Possibly the bug is due to the recursive runtime PM handling. Could you check the patch below? thanks, Takashi --- diff --git a/sound/pci/hda/patch_ca0132.c b/sound/pci/hda/patch_ca0132.c --- a/sound/pci/hda/patch_ca0132.c +++ b/sound/pci/hda/patch_ca0132.c @@ -4417,12 +4417,14 @@ static void ca0132_process_dsp_response(struct hda_codec *codec, struct ca0132_spec *spec = codec->spec; codec_dbg(codec, "ca0132_process_dsp_response\n"); + snd_hda_power_up_pm(codec); if (spec->wait_scp) { if (dspio_get_response_data(codec) >= 0) spec->wait_scp = 0; } dspio_clear_response_queue(codec); + snd_hda_power_down_pm(codec); } static void hp_callback(struct hda_codec *codec, struct hda_jack_callback *cb)