Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp398343ybk; Fri, 15 May 2020 03:45:23 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw1hIbzPBnuJB2yD8uLd5hmQvx6jvrIDojfzNhck+DwQVQkIBL05L7rLbd43Lx36k9DkKLv X-Received: by 2002:a50:cb85:: with SMTP id k5mr2240150edi.152.1589539523662; Fri, 15 May 2020 03:45:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589539523; cv=none; d=google.com; s=arc-20160816; b=Pi+qseuFumagJ4HW1hOBpwOieGsDI1Flie6gBssCf42g0NCdz0MiMKLzafhBh1KOkX w48iQXcNMryTS/nNZ629nzOErQX5ct6mHxluS6Q/V7+7+d1UzyIGk+2DqsgJgfCIEPtF GVOlDd3roznskgRhF5ZnOKmZAvlcE4JnrjGgKaDB8BTebi4/6CSf5uk3+iSYChF2sCpy 8L2gDJzxfzGngpiqJ13WrMh/OAC+I2fwTXKtzvbqItkNGgVqE3iDfm2rqDtK9BZlnSVo d+8z4cSyODWW9oVBZIHFgN+HikuSQVUef1dwQFPYZxaG0jI3uw6VY6kCBC0DGX7l+XQh L4tg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:subject:cc:to:from:message-id:date; bh=2mtBAMkDaGtouu/45VcKH1wdHnClADO3q4QQCAQw9tc=; b=L1QWSxfRtU7iwJyiDbSmCfcvTWJ24Y6Dx4MOqQgnNkD1FEejy6yQqbR/AU1dus+3jp zi3pTCI9pYmC4gEpevmkJGgQa72wCpR2ghkSpieR/vLZZkx2Yz/mTDsZK2orDsm9mGl4 mWPb4Yysjcm13dPdQJY8X5ZAVyP+JEb7AOinMLWF8SKlt/I5EpNylI+W9SVIBK5yKzkw Lh2wfb4qpXQVt7RkGRLeBgkc/2aZaGQAG6OtlPnOkxscqD7UqlBji7FwU9k5jxMivB9S am2sQsYJ33D5zTmYcS47SheN9HMm/WCCvEwEB1hXX7YviJB3VMSRp51MC2jMQsWlea8z O+OQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r10si921595edo.137.2020.05.15.03.45.00; Fri, 15 May 2020 03:45:23 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728289AbgEOKkp (ORCPT + 99 others); Fri, 15 May 2020 06:40:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:46494 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728013AbgEOKkp (ORCPT ); Fri, 15 May 2020 06:40:45 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id A5267AC5F; Fri, 15 May 2020 10:40:45 +0000 (UTC) Date: Fri, 15 May 2020 12:40:42 +0200 Message-ID: From: Takashi Iwai To: "Lu, Brent" Cc: "alsa-devel@alsa-project.org" , "Jaroslav Kysela" , Takashi Iwai , Baolin Wang , Arnd Bergmann , Greg Kroah-Hartman , Richard Fontana , "Thomas Gleixner" , paulhsia , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] ALSA: pcm: fix incorrect hw_base increase In-Reply-To: References: <1589515779-20987-1-git-send-email-brent.lu@intel.com> 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 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 May 2020 11:36:19 +0200, Lu, Brent wrote: > > > > > Updating hw_ptr_jiffies at that code path looks correct, but it still leaves the > > question why this condition happens. It means that the actual hwptr isn't > > changed and yet only jiffies increase significantly; it means that the hardware > > can't report proper pointer, and it should have set > > SNDRV_PCM_INFO_BATCH flag, then the jiffies check is skipped. > > > > With which hardware and under which situation did it happen (and the patch > > fixed)? > > > > > > thanks, > > > > Takashi > > > > >From time to time we got questions from google about why sometimes the > snd_pcm_avail() returns a value larger than buffer size. Recently we finally > found reliable reproduce steps: it's on Intel GLK Chromebook Fleex with > SOF firmware. There is a 1/20 chance the audio playback to HDMI fails. > > >From the FW side we observe a buffer runderrun, the FW is not able to > recover it for some reason and stops the pipe. > > >From the Linux side we see the pos does not increase because the FW stops > receiving data but suddenly the hw_prt is increased by buffer_size (16368). > It could make snd_pcm_avail() reporting a false underrun to the caller like > following log: > > 2020-05-09T16:08:32.712042+08:00 DEBUG kernel: [ 418.510086] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 4096 avail 12368 > 2020-05-09T16:08:32.712043+08:00 DEBUG kernel: [ 418.510149] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 6910 avail 9554 > ... > 2020-05-09T16:08:32.883095+08:00 DEBUG kernel: [ 418.680868] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362 > 2020-05-09T16:08:32.883104+08:00 DEBUG kernel: [ 418.681052] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 15102 avail 1362 > 2020-05-09T16:08:32.883109+08:00 DEBUG kernel: [ 418.681130] sound pcmC0D5p: pos 96 hw_ptr 96 appl_ptr 16464 avail 0 > 2020-05-09T16:08:32.929330+08:00 DEBUG kernel: [ 418.726515] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368 > 2020-05-09T16:08:32.929512+08:00 DEBUG kernel: [ 418.727041] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 16464 avail 16368 > > Or it could make snd_pcm_avail() returns an invalid number and confuses the > Caller like following log: > > 2020-05-09T16:08:33.054039+08:00 DEBUG kernel: [ 418.851755] sound pcmC0D5p: pos 96 hw_ptr 16464 appl_ptr 27390 avail 5442 > 2020-05-09T16:08:33.129552+08:00 DEBUG kernel: [ 418.926491] sound pcmC0D5p: pos 96 hw_ptr 32832 appl_ptr 27390 avail 21810 > 2020-05-09T16:08:33.131746+08:00 ERR cras_server[1907]: pcm_avail returned frames larger than buf_size: sof-glkda7219max: :0,5: 21810 > 16368 > > I've submitted a patch to fix the issue in SOF side. However, I think it's also good > to fix the incorrect hw_base increasement in Linux side. > > https://github.com/thesofproject/sof/pull/2926 Oh this whole information (at least some digested version) should have been included in the patch description. Otherwise we have no idea why it's needed and what actually means. Let's wait for Jaroslav's review, and if it's OK, could you resubmit with more description? thanks, Takashi