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 DDA51C4332F for ; Fri, 9 Dec 2022 08:11:17 +0000 (UTC) Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 089981FA0; Fri, 9 Dec 2022 09:10:25 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 089981FA0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1670573475; bh=Ean3R9bjPxdS+CWFQpm4IW+2P6Y72b4UY4mRHShU4lQ=; h=Date:From:To:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=YD8yw+jWt/SukZ36gQjVMJjazw6m0hNDkYQwVt8X9Rjs4h9WccMxo9Tf9VWLnZNKq IjFqNRdr62ZwQnfgbWDSAxaHfa8mC90k4jKRdOnaR/EBl6ZEJtZV0+8V8OZowWCChe JyQLDRhJgkd8FwbaP8JLVgUmJrN3oYOIU35S0Eug= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id B5BEDF8022B; Fri, 9 Dec 2022 09:10:24 +0100 (CET) Received: by alsa1.perex.cz (Postfix, from userid 50401) id D00ADF8022D; Fri, 9 Dec 2022 09:10:22 +0100 (CET) Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) (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 alsa1.perex.cz (Postfix) with ESMTPS id 2D0CDF8016E for ; Fri, 9 Dec 2022 09:10:20 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz 2D0CDF8016E Authentication-Results: alsa1.perex.cz; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=viT6BMxf; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=+rAeGYUt Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 7035822ADC; Fri, 9 Dec 2022 08:10:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1670573420; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TxDCO0feW92TTekFzWHxCZxRg4MCYDArXps4Xu9X1c8=; b=viT6BMxfjXO6v+XAGRqoLGgSd4zykA1v48ZTklKZOHHykVWDzaKCq94/6bZE5sBMghO2tg x0DmT6F0p1O6HNUwBKoMD4yqM026eis04n2iS8H23gkrIIWZuPRIXTxSdSrZqysQP6xFTx hJKIe58Eaz8FJEElxcgUMxwL5Ca2ptw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1670573420; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TxDCO0feW92TTekFzWHxCZxRg4MCYDArXps4Xu9X1c8=; b=+rAeGYUtFvxZacIXXLqi8o+Ujdq534gkW8ZMpMb+LInwv0VAdg0O1BaqhTKh69Erg+MgpM SZ7deBxI2ZDKNkBg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 4CB3F138E0; Fri, 9 Dec 2022 08:10:20 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id w//8EWztkmPSOQAAMHmgww (envelope-from ); Fri, 09 Dec 2022 08:10:20 +0000 Date: Fri, 09 Dec 2022 09:10:19 +0100 Message-ID: <87tu256lqs.wl-tiwai@suse.de> From: Takashi Iwai To: Marek =?ISO-8859-1?Q?Marczykowski-G=F3recki?= Subject: Re: Intel HD Audio: sound stops working in Xen PV dom0 in >=5.17 In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.2 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.29 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: , Cc: alsa-devel@alsa-project.org, Harald Arnesen , Alex Xu Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" On Fri, 09 Dec 2022 02:27:30 +0100, Marek Marczykowski-Górecki wrote: > > Hi, > > Under Xen PV dom0, with Linux >= 5.17, sound stops working after few > hours. pavucontrol still shows meter bars moving, but the speakers > remain silent. At least on some occasions I see the following message in > dmesg: > > [ 2142.484553] snd_hda_intel 0000:00:1f.3: Unstable LPIB (18144 >= 6396); disabling LPIB delay counting > > I'm not sure if that happens before sound stops working, after, of if > it's related at all, but that's pretty much the only sound-related error > I found in logs. > When the issue happens, on rare occasions it starts working again later > for a short time, but generally the fix is to reboot. Reloading all > snd_* modules (surprisingly) do not help. I don't know what exactly > triggers the issue, sometimes is happen after short time like 15 minutes > uptime, but usually after several hours. I guess it depends on usage > pattern, but I haven't spotted any specific relation. > > I managed to bisect it to this commit: > > 2c95b92ecd92e784785b1db8cccc4f0f2bfa850c is the first bad commit > commit 2c95b92ecd92e784785b1db8cccc4f0f2bfa850c > Author: Takashi Iwai > Date: Tue Nov 16 08:33:58 2021 +0100 > > ALSA: memalloc: Unify x86 SG-buffer handling (take#3) > > This is a second attempt to unify the x86-specific SG-buffer handling > code with the new standard non-contiguous page handler. > > The first try (in commit 2d9ea39917a4) failed due to the wrong page > and address calculations, hence reverted. (And the second try failed > due to a copy&paste error.) Now it's corrected with the previous fix > for noncontig pages, and the proper sg page iteration by this patch. > > After the migration, SNDRV_DMA_TYPE_DMA_SG becomes identical with > SNDRV_DMA_TYPE_NONCONTIG on x86, while others still fall back to > SNDRV_DMA_TYPE_DEV. > > Tested-by: Alex Xu (Hello71) > Tested-by: Harald Arnesen > Link: https://lore.kernel.org/r/20211017074859.24112-4-tiwai@suse.de > Link: https://lore.kernel.org/r/20211109062235.22310-1-tiwai@suse.de > Link: https://lore.kernel.org/r/20211116073358.19741-1-tiwai@suse.de > Signed-off-by: Takashi Iwai > > include/sound/memalloc.h | 14 ++-- > sound/core/Makefile | 1 - > sound/core/memalloc.c | 53 ++++++++++++- > sound/core/sgbuf.c | 201 ----------------------------------------------- > 4 files changed, 56 insertions(+), 213 deletions(-) > delete mode 100644 sound/core/sgbuf.c > > I've seen further follow ups to this commit, but I still observe this > issue on Linux 6.0.8. > > I have observed this issue on KBL-based system, but I've got reports > also from users of other platforms (including as old as Sandy Bridge). > > I tried to include all relevant information above, but some more details > can be found at original report at > https://github.com/QubesOS/qubes-issues/issues/7465 > > Any ideas? Hm, is it specific to Xen, i.e. if you run the normal kernel on the same machine, does it still work? In anyway, please check the behavior with 6.1-rc8 + the commit cc26516374065a34e10c9a8bf3e940e42cd96e2a ALSA: memalloc: Allocate more contiguous pages for fallback case from for-next of my sound git tree (which will be in 6.2-rc1). If the problem persists, another thing to check is the hack below works. thanks, Takashi -- 8< -- --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -1808,9 +1808,16 @@ static int azx_create(struct snd_card *card, struct pci_dev *pci, if (err < 0) return err; +#if 0 /* use the non-cached pages in non-snoop mode */ if (!azx_snoop(chip)) azx_bus(chip)->dma_type = SNDRV_DMA_TYPE_DEV_WC_SG; +#else + if (!azx_snoop(chip)) + azx_bus(chip)->dma_type = SNDRV_DMA_TYPE_DEV_SG; + else + azx_bus(chip)->dma_type = SNDRV_DMA_TYPE_DEV; +#endif if (chip->driver_type == AZX_DRIVER_NVIDIA) { dev_dbg(chip->card->dev, "Enable delay in RIRB handling\n");