From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id CC79844E64E; Fri, 9 Oct 2026 13:22:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=195.135.223.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791552169; cv=none; b=CEZknzYiiA3Fn1Q1vxNnWa+CU5AAydY9OgovRp8Fl+NBLYvv5V+VX12Ky/5Fw5qIKqMEVWRPa5GawQt8QWyGI1XTwSG8dPf2Yo2N5Dl07cn3n7SRDkW5NTeQtmwCSYH9SLMDFOlykHpG/RPEpAaQwx/wYMy49B8LyXielHdJ/Xg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791552169; c=relaxed/simple; bh=eMHoNSdHzps7Aih6g5jyMqPYdINzs7QugqJQETGVXS8=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=TUam1rXVGJMWBYJS0PhyNuyrqAZbxDHxW8j48YZOyNpcln567ASJPKLTiRcL3O8Q9Xdu8XboKNUfOP3bta7DsXGIGH02l9IlR7i8enS7EJsNt5T9U5vxZ/+eYZr7AvEAfUWFGCcGillJpE9yonB30JMOY68l6dByzkZrp5qiAm0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de; spf=pass smtp.mailfrom=suse.de; arc=none smtp.client-ip=195.135.223.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.de Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id DAC711F7CB; Fri, 9 Oct 2026 13:22:45 +0000 (UTC) Authentication-Results: smtp-out2.suse.de; none Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 91F691326D; Fri, 9 Oct 2026 13:22:45 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id eZiOGaXqyGqCWgAAD6G6ig (envelope-from ); Fri, 09 Oct 2026 13:22:45 +0000 Date: Fri, 09 Oct 2026 15:22:45 +0200 Message-ID: <87o6d33t5m.wl-tiwai@suse.de> From: Takashi Iwai To: songxiebing Cc: tiwai@suse.com, perex@perex.cz, linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ALSA: hda: Reset pending verb count on response timeout In-Reply-To: <20261009034040.379171-1-songxiebing@kylinos.cn> References: <20261009034040.379171-1-songxiebing@kylinos.cn> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/30.2 Mule/6.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Spamd-Bar: / X-Rspamd-Queue-Id: DAC711F7CB X-Rspamd-Pre-Result: action=no action; module=Unknown lua; unknown reason X-Rspamd-Action: no action X-Spam-Flag: NO X-Spam-Score: 0.00 X-Spam-Level: X-Rspamd-Server: rspamd2.dmz-prg2.suse.org X-Spamd-Result: default: False [0.00 / 50.00] On Fri, 09 Oct 2026 05:40:40 +0200, songxiebing wrote: > > From: Bob Song > > On some controllers the HDA link reports a verb timeout and the driver > falls back to polling mode. After that, every subsequent verb sent to > that codec address keeps timing out (roughly one second per verb), while > the hardware itself looks perfectly healthy: the RIRB write pointer keeps > advancing, interrupts are still delivered, and verbs that carry no reply > payload -- notably writes -- still take effect on the codec. > > The reason is that snd_hdac_bus_send_cmd() increments > bus->rirb.cmds[addr] for every verb, but the counter is only decremented > by snd_hdac_bus_update_rirb() when a matching RIRB response is read, with > no rollback if the response never arrives. > > When a controller cannot fall back to single-command mode, i.e. > chip->fallback_to_single_cmd is zero, azx_rirb_get_response() bails out > with -EIO immediately and never reaches the bus-reset / single_cmd > recovery that reinitializes CORB/RIRB and clears the counters (that path > is guarded by the same flag). The ACPI platform, Tegra and CIX > controllers never set that flag, so they are all exposed to this. > > A single lost response therefore poisons bus->rirb.cmds[addr] > permanently: each later verb still gets one response that only brings the > count back down to the stale baseline of 1, so > snd_hdac_bus_get_response() keeps timing out even though the codec > answers normally. > > Fix this by dropping the pending count for the codec address once the > verb is known to be dead. A late response is then handled as a spurious > response exactly as before, and the following verbs recover. > > Signed-off-by: Bob Song Thanks for the patch. I think, however, that it's better to fix in the hda core side, i.e. snd_hdac_bus_exec_verb_unlocked(). When bus->ops->get_response() gets an error, just reset bus->rirb.cmds[addr]. Maybe create a helper (e.g. snd_hdac_bus_reset_response_counter(buf, addr)) in sound/hda/core/controller.c, and call it instead of open-code to make the meaning clearer. In this way, it'll cover all HD-audio controllers, not only hda-intel. Takashi