From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 76C76C433F5 for ; Wed, 23 Mar 2022 19:07:00 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 3BB6316B0; Wed, 23 Mar 2022 20:06:08 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 3BB6316B0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1648062418; bh=1/4plweIDSQWFIn+3YPbq91twXgY8xdpxbiLxo8HJ7Q=; h=Date:From:To:Subject:In-Reply-To:References:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=GETcMmpr/vprPOQzPXlnBtFXoXjtpo5WFZZjDGTkBAcx+/BIfBrjddvXz2S5AwLiV ByfbtWTNz30saZKa7B8LPRmmlYuhJ/1QA8RKMJa3r/6drhhJzC3y73hAHLZgzAxdV6 l99B7ahUZXPxQKSS7duRVUM9PVvgUUiI4vmv2vLs= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id 8A107F80165; Wed, 23 Mar 2022 20:06:07 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 5010DF802DB; Wed, 23 Mar 2022 20:06:05 +0100 (CET) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id 27C21F800C1 for ; Wed, 23 Mar 2022 20:05:57 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 27C21F800C1 Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.b="Sy3LVS2P"; dkim=permerror (0-bit key) header.d=suse.de header.i=@suse.de header.b="hG2NIR68" Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 1E0C7210F8; Wed, 23 Mar 2022 19:05:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1648062357; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bVuhXXAemclRPjBH29/ee1EiYvwc8RkX0IMQfHfC6XI=; b=Sy3LVS2PPYcJUKFhzjo41AE8uUOUOc4JTIapQXgJ1EiE8w1zwmLlFxF0CGPQbRkLt7fW3x WUPpOcIL8tK1U13a/heI1e1rG9135q/gxYVkBkNIkxf6Zup70ufBhb+/R/AaFv79gJm6Gz dDz1CkUaweBgAugPtqM3JvtGLi1brRA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1648062357; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=bVuhXXAemclRPjBH29/ee1EiYvwc8RkX0IMQfHfC6XI=; b=hG2NIR687XAu58QaMLdILXv+PilBX9bmRVkc+8kFOdclyoXROm5TT0G8Dtp+sk+RlfVtmy u+cZxZ1Co4iFydCQ== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 0D353A3B87; Wed, 23 Mar 2022 19:05:57 +0000 (UTC) Date: Wed, 23 Mar 2022 20:05:57 +0100 Message-ID: From: Takashi Iwai To: Jason Andryuk Subject: Re: snd_hda_intel initialization failure with Xen PCI passthrough In-Reply-To: References: 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.3 (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 Cc: alsa-devel@alsa-project.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Wed, 23 Mar 2022 19:52:21 +0100, Jason Andryuk wrote: > > On Wed, Mar 23, 2022 at 5:41 AM Takashi Iwai wrote: > > > > On Tue, 22 Mar 2022 19:57:27 +0100, > > Jason Andryuk wrote: > > > > > > Hi, > > > > > > I'm running Xen hypervisor and using PCI passthrough to assign an > > > Intel HDA audio device (00:1f.3 Audio device: Intel Corporation Cannon > > > Point-LP High Definition Audio Controller (rev 30)) to a Xen HVM > > > virtual machine. I do this for both Linux 5.4.185 and a different > > > Windows 10 VM (only one at a time). The Windows VM seems to work > > > every time. The Linux VM has issues after the first VM boot. This is > > > one boot of the physical hardware and multiple boots of the virtual > > > machines. > > > > > > For Linux, on first boot, the sound card is detected and works > > > properly. After that, things usually don't work. I just ran a reboot > > > loop and it was: > > > 1st boot - audio detected and working > > > 2 & 3 - no audio > > > 4th - audio detected and working > > > 5 - 20 - no audio > > > > > > For boots 2, 3, 5-7, dmesg shows: > > > [ 0.760401] hdaudio hdaudioC0D0: no AFG or MFG node found > > > [ 0.760415] snd_hda_intel 0000:00:06.0: no codecs initialized > > > > > > For boots 8+, the errors changed to: > > > [ 0.783397] hdaudio hdaudioC0D0: cannot read sub nodes for FG 0x10 > > > [ 0.783413] snd_hda_intel 0000:00:06.0: no codecs initialized > > > > > > At this point, I booted a Windows 10 VM and audio works > > > > > > Trying to boot Linux again gives a new error message > > > [ 0.789041] snd_hda_intel 0000:00:06.0: Unknown capability 0 > > > [ 1.811205] snd_hda_intel 0000:00:06.0: No response from codec, > > > resetting bus: last cmd=0x0eef0004 > > > [ 1.811246] hdaudio hdaudioC0D0: cannot read sub nodes for FG 0x10ee > > > [ 1.811263] snd_hda_intel 0000:00:06.0: no codecs initialized > > > > > > Reboot VM and it's back to: > > > [ 0.775917] hdaudio hdaudioC0D0: no AFG or MFG node found > > > [ 0.775932] snd_hda_intel 0000:00:06.0: no codecs initialized > > > > > > Reboot VM and again: > > > [ 0.789069] hdaudio hdaudioC0D0: cannot read sub nodes for FG 0x10 > > > [ 0.789084] snd_hda_intel 0000:00:06.0: no codecs initialized > > > > > > Reboot physical laptop: > > > 1. boot Windows 10 - audio works > > > 2. boot Linux - audio works > > > 3. reboot Linux - no audio > > > [ 0.773111] hdaudio hdaudioC0D0: no AFG or MFG node found > > > [ 0.773151] snd_hda_intel 0000:00:06.0: no codecs initialized > > > > > > This seems to me like Windows does a better job resetting the card to > > > get the audio hardware working. Any suggestions on what to > > > investigate? > > Thanks for taking a look, Takashi. > > > First off, 5.4.x is way too old to debug, please confirm the issue > > with the latest kernel. > > > > And, one test I'd try is to unload snd-hda-intel module before > > rebooting. Does the problem persist? > > For my 5.4.186 VM, the module is built-in. I tried `echo 0000:00:03.0 > > /sys/bus/pci/driver/snd_hda_intel/unbind` before rebooting, but that > did not work. > > I switched to Fedora 35 in the VM with kernel 5.16.16. That worked > the first time and failed the second. > > First working: > [ 3.094907] snd_hda_intel 0000:00:06.0: DSP detected with PCI > class/subclass/prog-if info 0x040380 > [ 3.094912] snd_hda_intel 0000:00:06.0: NHLT table not found > [ 3.197480] snd_hda_codec_realtek hdaudioC0D0: autoconfig for > ALC3204: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker > [ 3.197484] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 > (0x0/0x0/0x0/0x0/0x0) > [ 3.197485] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 > (0x21/0x0/0x0/0x0/0x0) > [ 3.197486] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 > [ 3.197487] snd_hda_codec_realtek hdaudioC0D0: inputs: > [ 3.197488] snd_hda_codec_realtek hdaudioC0D0: Headset Mic=0x19 > [ 3.197489] snd_hda_codec_realtek hdaudioC0D0: Headphone Mic=0x1a > [ 3.197489] snd_hda_codec_realtek hdaudioC0D0: Internal Mic=0x12 > [ 66.801958] snd_hda_intel 0000:00:06.0: azx_get_response timeout, > switching to polling mode: last cmd=0x00170500 > > Second boot audio still failed after doing `echo 0000:00:06.0 > > /sys/bus/pci/driver/snd_hda_intel/unbind` and rmmod-ing lots of snd_* > modules. I rmmod-ed the snd_*intel ones, but other snd* modules > including snd_hrtimer were in use and could not be removed. That's weird. If you logout the desktop and go to VT, you can unload snd-hda-intel. Then the other modules should be unloadable. And do you see the problem without VM? That is, the host shows the same symptom? Takashi