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 X-Spam-Level: X-Spam-Status: No, score=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 83D38C07E95 for ; Wed, 7 Jul 2021 07:02:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 6504A61CA8 for ; Wed, 7 Jul 2021 07:02:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230361AbhGGHFG (ORCPT ); Wed, 7 Jul 2021 03:05:06 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:59530 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230312AbhGGHFF (ORCPT ); Wed, 7 Jul 2021 03:05:05 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 8EC652256E; Wed, 7 Jul 2021 07:02:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1625641344; 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=Op8kaXWmQZkP/t6/Ou7GdSs3p7QU40ls+HE/eSEJmzE=; b=qUT+LTJk6hK1jroj3RseadRL2UFbUWUm6vbxoHNviHXnJKWvnAr0jSOQ70ZM/M3XwuRKG1 F6GNPSbtsubJQ7WcSTF7vb/N4V+EBrzAvHKiUOMVtA8vK5qbwGE571iLf1BARsPRa69FQ6 pQ7OSntYWTDQLoPcqX9M4Rt7tnzyp6o= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1625641344; 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=Op8kaXWmQZkP/t6/Ou7GdSs3p7QU40ls+HE/eSEJmzE=; b=XNhXEDwCYFKryqq6ypDCSUMWq3feyFuI+Cx97Kgj8tzhZjl1/X6TNxfMDtWjGXPNngKezM AaRn6o8XbZfc3/BA== Received: from alsa1.suse.de (alsa1.suse.de [10.160.4.42]) by relay2.suse.de (Postfix) with ESMTP id 81D95A3B8A; Wed, 7 Jul 2021 07:02:24 +0000 (UTC) Date: Wed, 07 Jul 2021 09:02:24 +0200 Message-ID: From: Takashi Iwai To: Max Filippov Cc: Sergey Senozhatsky , alsa-devel@alsa-project.org, Leon Romanovsky , Takashi Iwai , LKML , "Gustavo A. R. Silva" Subject: Re: ALSA: intel8x0: div by zero in snd_intel8x0_update() 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 06 Jul 2021 19:50:08 +0200, Max Filippov wrote: > > Hello, > > On Sun, May 16, 2021 at 2:50 AM Takashi Iwai wrote: > > > > On Sun, 16 May 2021 10:31:41 +0200, > > Sergey Senozhatsky wrote: > > > > > > On (21/05/16 17:30), Sergey Senozhatsky wrote: > > > > On (21/05/14 20:16), Sergey Senozhatsky wrote: > > > > > > --- a/sound/pci/intel8x0.c > > > > > > +++ b/sound/pci/intel8x0.c > > > > > > @@ -691,6 +691,9 @@ static inline void snd_intel8x0_update(struct intel8x0 *chip, struct ichdev *ich > > > > > > int status, civ, i, step; > > > > > > int ack = 0; > > > > > > > > > > > > + if (!ichdev->substream || ichdev->suspended) > > > > > > + return; > > > > > > + > > > > > > spin_lock_irqsave(&chip->reg_lock, flags); > > > > > > status = igetbyte(chip, port + ichdev->roff_sr); > > > > > > civ = igetbyte(chip, port + ICH_REG_OFF_CIV); > > > > > > > > This does the problem for me. > > > > > > ^^^ does fix > > > > OK, thanks for confirmation. So this looks like some spurious > > interrupt with the unexpected hardware bits. > > > > However, the suggested check doesn't seem covering enough, and it > > might still hit if the suspend/resume happens before the device is > > opened but not set up (and such a spurious irq is triggered). > > > > Below is more comprehensive fix. Let me know if this works, too. > > > > > > thanks, > > > > Takashi > > > > -- 8< -- > > Subject: [PATCH] ALSA: intel8x0: Don't update period unless prepared > > > > The interrupt handler of intel8x0 calls snd_intel8x0_update() whenever > > the hardware sets the corresponding status bit for each stream. This > > works fine for most cases as long as the hardware behaves properly. > > But when the hardware gives a wrong bit set, this leads to a NULL > > dereference Oops, and reportedly, this seems what happened on a VM. > > > > For fixing the crash, this patch adds a internal flag indicating that > > the stream is ready to be updated, and check it (as well as the flag > > being in suspended) to ignore such spurious update. > > > > Cc: > > Reported-by: Sergey Senozhatsky > > Signed-off-by: Takashi Iwai > > --- > > sound/pci/intel8x0.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > linux v5.13 booting on qemu-system-xtensa virt board gets stuck inside > snd_intel8x0_probe -> intel8x0_measure_ac97_clock with this patch. > Prior to it it boots successfully for me. > I'm curious if this issue has been reported yet. > > What I see is an IRQ flood, at some point snd_intel8x0_interrupt > and timer ISR are called in loop and execution never returns to > the interrupted function intel8x0_measure_ac97_clock. > > Any idea what it could be? That's something odd with the VM. As the chip itself has never shown such a problem on real systems, maybe the best action would be to just skip the clock measurement on VM. The measurement itself is unreliable on VM, so it makes more sense. That said, something like below would work? thanks, Takashi --- diff --git a/sound/pci/intel8x0.c b/sound/pci/intel8x0.c index 2d1bfbcba933..b75f832d7777 100644 --- a/sound/pci/intel8x0.c +++ b/sound/pci/intel8x0.c @@ -2199,6 +2199,9 @@ static int snd_intel8x0_mixer(struct intel8x0 *chip, int ac97_clock, pbus->private_free = snd_intel8x0_mixer_free_ac97_bus; if (ac97_clock >= 8000 && ac97_clock <= 48000) pbus->clock = ac97_clock; + else if (chip->inside_vm) + pbus->clock = 48000; + /* FIXME: my test board doesn't work well with VRA... */ if (chip->device_type == DEVICE_ALI) pbus->no_vra = 1;