All of lore.kernel.org
 help / color / mirror / Atom feed
From: Takashi Iwai <tiwai@suse.de>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] sound fixes for 6.1-rc5
Date: Sat, 12 Nov 2022 09:46:43 +0100	[thread overview]
Message-ID: <87a64w7e6k.wl-tiwai@suse.de> (raw)
In-Reply-To: <CAHk-=wgSH5ubdvt76gNwa004ooZAEJL_1Q-Fyw5M2FDdqL==dg@mail.gmail.com>

On Sat, 12 Nov 2022 02:28:19 +0100,
Linus Torvalds wrote:
> 
> On Fri, Nov 11, 2022 at 12:56 AM Takashi Iwai <tiwai@suse.de> wrote:
> >
> > please pull sound fixes for v6.1-rc5 from:
> 
> Hmm. I don't know that this came in through this particular pull
> request, but I don't seem to have seen it before:
> 
>   Nov 11 14:32:37 xps13 kernel:
>         snd_hda_intel 0000:00:1f.3: Too many BDL entries:
> buffer=2097152, period=65536
> 
> there's six of those lines in my logs (two batches of three, five
> seconds apart).
> 
> I don't see any negative side effects aside from the messages, and
> sound seems to work fine, but since I don't think I've ever seen this
> one before I thought I'd just mention it.
> 
> I also haven't been using this laptop on a while - an arm64 Fedora
> uboot update broke my M2 boot, so I'm temporarily back to using my
> trusty old xps13.
> 
> So while it's new to me, the issue that introduced it may not be
> particularly new.
> 
> Google does show that the message itself has been happening for others
> for a long time. But I checked with 'journalctl', and it hasn't
> happened on this particular machine before.
> 
> It might be a non-kernel change that triggers it, of course.

Wooh, that must be the last change in the memalloc helper for
non-contiguous pages :-<  Admittedly the fix was a bit premature,
sorry for the mess.

Below is the quick workaround.  I'm going to send another PR soon
later.


thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: memalloc: Try dma_alloc_noncontiguous() at first

The latest fix for the non-contiguous memalloc helper changed the
allocation method for a non-IOMMU system to use only the fallback
allocator.  This should have worked, but it caused a problem sometimes
when too many non-contiguous pages are allocated that can't be treated
by HD-audio controller.

As a quirk workaround, go back to the original strategy: use
dma_alloc_noncontiguous() at first, and apply the fallback only when
it fails, but only for non-IOMMU case.

We'll need a better fix in the fallback code as well, but this
workaround should paper over most cases.

Fixes: 9736a325137b ("ALSA: memalloc: Don't fall back for SG-buffer with IOMMU")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/CAHk-=wgSH5ubdvt76gNwa004ooZAEJL_1Q-Fyw5M2FDdqL==dg@mail.gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/core/memalloc.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/sound/core/memalloc.c b/sound/core/memalloc.c
index 6a81aaab25ab..ba095558b6d1 100644
--- a/sound/core/memalloc.c
+++ b/sound/core/memalloc.c
@@ -542,8 +542,10 @@ static void *snd_dma_noncontig_alloc(struct snd_dma_buffer *dmab, size_t size)
 	struct sg_table *sgt;
 	void *p;
 
+	sgt = dma_alloc_noncontiguous(dmab->dev.dev, size, dmab->dev.dir,
+				      DEFAULT_GFP, 0);
 #ifdef CONFIG_SND_DMA_SGBUF
-	if (!get_dma_ops(dmab->dev.dev)) {
+	if (!sgt && !get_dma_ops(dmab->dev.dev)) {
 		if (dmab->dev.type == SNDRV_DMA_TYPE_DEV_WC_SG)
 			dmab->dev.type = SNDRV_DMA_TYPE_DEV_WC_SG_FALLBACK;
 		else
@@ -551,9 +553,6 @@ static void *snd_dma_noncontig_alloc(struct snd_dma_buffer *dmab, size_t size)
 		return snd_dma_sg_fallback_alloc(dmab, size);
 	}
 #endif
-
-	sgt = dma_alloc_noncontiguous(dmab->dev.dev, size, dmab->dev.dir,
-				      DEFAULT_GFP, 0);
 	if (!sgt)
 		return NULL;
 
-- 
2.35.3


      reply	other threads:[~2022-11-12  8:48 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11  8:56 [GIT PULL] sound fixes for 6.1-rc5 Takashi Iwai
2022-11-11 18:03 ` pr-tracker-bot
2022-11-12  1:28 ` Linus Torvalds
2022-11-12  8:46   ` Takashi Iwai [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a64w7e6k.wl-tiwai@suse.de \
    --to=tiwai@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.