regressions.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* Kernel 5.13.6 breaks mmap with snd-hdsp module
@ 2021-08-07  7:49 Jeff Woods
  2021-08-07  8:16 ` Greg KH
  0 siblings, 1 reply; 8+ messages in thread
From: Jeff Woods @ 2021-08-07  7:49 UTC (permalink / raw)
  To: stable; +Cc: regressions

Specifically, commit c4824ae7db418aee6f50f308a20b832e58e997fd triggers the problem. Reverting this change restores functionality.

The device is an RME Multiface II, using the snd-hdsp driver.

Expected behavior: Device plays sound normally

Exhibited behavior: When a program attempts to open the device, the following ALSA lib error happens:

ALSA lib pcm_direct.c:1169:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access

This change hasn't affected my other computers with less esoteric hardware, so probably the problem lies with the snd-hdsp driver, but the device is unusable without reverting that commit.

I am available to test any patches for this issue.

Thanks,
J Woods

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Kernel 5.13.6 breaks mmap with snd-hdsp module
  2021-08-07  7:49 Kernel 5.13.6 breaks mmap with snd-hdsp module Jeff Woods
@ 2021-08-07  8:16 ` Greg KH
  2021-08-07  9:26   ` Takashi Iwai
  0 siblings, 1 reply; 8+ messages in thread
From: Greg KH @ 2021-08-07  8:16 UTC (permalink / raw)
  To: Takashi Iwai, Jeff Woods; +Cc: alsa-devel, stable, regressions

On Sat, Aug 07, 2021 at 12:49:07AM -0700, Jeff Woods wrote:
> Specifically, commit c4824ae7db418aee6f50f308a20b832e58e997fd triggers the problem. Reverting this change restores functionality.
> 
> The device is an RME Multiface II, using the snd-hdsp driver.
> 
> Expected behavior: Device plays sound normally
> 
> Exhibited behavior: When a program attempts to open the device, the following ALSA lib error happens:
> 
> ALSA lib pcm_direct.c:1169:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access
> 
> This change hasn't affected my other computers with less esoteric hardware, so probably the problem lies with the snd-hdsp driver, but the device is unusable without reverting that commit.
> 
> I am available to test any patches for this issue.

Have you notified the developers involved in this change about this
issue?

Adding them now...

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Kernel 5.13.6 breaks mmap with snd-hdsp module
  2021-08-07  8:16 ` Greg KH
@ 2021-08-07  9:26   ` Takashi Iwai
  2021-08-07 22:51     ` Jeff Woods
  0 siblings, 1 reply; 8+ messages in thread
From: Takashi Iwai @ 2021-08-07  9:26 UTC (permalink / raw)
  To: Greg KH; +Cc: Jeff Woods, alsa-devel, stable, regressions

On Sat, 07 Aug 2021 10:16:47 +0200,
Greg KH wrote:
> 
> On Sat, Aug 07, 2021 at 12:49:07AM -0700, Jeff Woods wrote:
> > Specifically, commit c4824ae7db418aee6f50f308a20b832e58e997fd triggers the problem. Reverting this change restores functionality.
> > 
> > The device is an RME Multiface II, using the snd-hdsp driver.
> > 
> > Expected behavior: Device plays sound normally
> > 
> > Exhibited behavior: When a program attempts to open the device, the following ALSA lib error happens:
> > 
> > ALSA lib pcm_direct.c:1169:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access
> > 
> > This change hasn't affected my other computers with less esoteric hardware, so probably the problem lies with the snd-hdsp driver, but the device is unusable without reverting that commit.
> > 
> > I am available to test any patches for this issue.
> 
> Have you notified the developers involved in this change about this
> issue?

No, it's a new report :)

> Adding them now...

Could you try the patch below?


thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: pci: rme: Fix mmap breakage

The recent change in the PCM core restricts the mmap of unknown buffer
type, and this broke the mmap on RME9652 and HDSP drivers that didn't
set up properly.  Actually those driver do use the buffers allocated
in a standard way, and the proper calls should fix the breakage.

Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/pci/rme9652/hdsp.c    | 6 ++----
 sound/pci/rme9652/rme9652.c | 6 ++----
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/sound/pci/rme9652/hdsp.c b/sound/pci/rme9652/hdsp.c
index 8457a4bbc3df..b32a72e28917 100644
--- a/sound/pci/rme9652/hdsp.c
+++ b/sound/pci/rme9652/hdsp.c
@@ -4518,8 +4518,7 @@ static int snd_hdsp_playback_open(struct snd_pcm_substream *substream)
 	snd_pcm_set_sync(substream);
 
         runtime->hw = snd_hdsp_playback_subinfo;
-	runtime->dma_area = hdsp->playback_buffer;
-	runtime->dma_bytes = HDSP_DMA_AREA_BYTES;
+	snd_pcm_set_runtime_buffer(substream, hdsp->playback_dma_buf);
 
 	hdsp->playback_pid = current->pid;
 	hdsp->playback_substream = substream;
@@ -4595,8 +4594,7 @@ static int snd_hdsp_capture_open(struct snd_pcm_substream *substream)
 	snd_pcm_set_sync(substream);
 
 	runtime->hw = snd_hdsp_capture_subinfo;
-	runtime->dma_area = hdsp->capture_buffer;
-	runtime->dma_bytes = HDSP_DMA_AREA_BYTES;
+	snd_pcm_set_runtime_buffer(substream, hdsp->capture_dma_buf);
 
 	hdsp->capture_pid = current->pid;
 	hdsp->capture_substream = substream;
diff --git a/sound/pci/rme9652/rme9652.c b/sound/pci/rme9652/rme9652.c
index f1aad38760d6..8036ed761d53 100644
--- a/sound/pci/rme9652/rme9652.c
+++ b/sound/pci/rme9652/rme9652.c
@@ -2279,8 +2279,7 @@ static int snd_rme9652_playback_open(struct snd_pcm_substream *substream)
 	snd_pcm_set_sync(substream);
 
         runtime->hw = snd_rme9652_playback_subinfo;
-	runtime->dma_area = rme9652->playback_buffer;
-	runtime->dma_bytes = RME9652_DMA_AREA_BYTES;
+	snd_pcm_set_runtime_buffer(substream, rme9652->playback_dma_buf);
 
 	if (rme9652->capture_substream == NULL) {
 		rme9652_stop(rme9652);
@@ -2339,8 +2338,7 @@ static int snd_rme9652_capture_open(struct snd_pcm_substream *substream)
 	snd_pcm_set_sync(substream);
 
 	runtime->hw = snd_rme9652_capture_subinfo;
-	runtime->dma_area = rme9652->capture_buffer;
-	runtime->dma_bytes = RME9652_DMA_AREA_BYTES;
+	snd_pcm_set_runtime_buffer(substream, rme9652->capture_dma_buf);
 
 	if (rme9652->playback_substream == NULL) {
 		rme9652_stop(rme9652);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: Kernel 5.13.6 breaks mmap with snd-hdsp module
  2021-08-07  9:26   ` Takashi Iwai
@ 2021-08-07 22:51     ` Jeff Woods
  2021-08-08  7:01       ` Takashi Iwai
  0 siblings, 1 reply; 8+ messages in thread
From: Jeff Woods @ 2021-08-07 22:51 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: Greg KH, alsa-devel, stable, regressions

 ---- On Sat, 07 Aug 2021 02:26:32 -0700 Takashi Iwai <tiwai@suse.de> wrote ----
 > On Sat, 07 Aug 2021 10:16:47 +0200,
 > Greg KH wrote:
 > > 
 > > On Sat, Aug 07, 2021 at 12:49:07AM -0700, Jeff Woods wrote:
 > > > Specifically, commit c4824ae7db418aee6f50f308a20b832e58e997fd triggers the problem. Reverting this change restores functionality.
 > > > 
 > > > The device is an RME Multiface II, using the snd-hdsp driver.
 > > > 
 > > > Expected behavior: Device plays sound normally
 > > > 
 > > > Exhibited behavior: When a program attempts to open the device, the following ALSA lib error happens:
 > > > 
 > > > ALSA lib pcm_direct.c:1169:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access
 > > > 
 > > > This change hasn't affected my other computers with less esoteric hardware, so probably the problem lies with the snd-hdsp driver, but the device is unusable without reverting that commit.
 > > > 
 > > > I am available to test any patches for this issue.
 > > 
 > > Have you notified the developers involved in this change about this
 > > issue?
 > 
 > No, it's a new report :)
 > 
 > > Adding them now...
 > 
 > Could you try the patch below?
 > 
 > 
 > thanks,
 > 
 > Takashi
 > 
 > -- 8< --
 > From: Takashi Iwai <tiwai@suse.de>
 > Subject: [PATCH] ALSA: pci: rme: Fix mmap breakage
 > 
 > The recent change in the PCM core restricts the mmap of unknown buffer
 > type, and this broke the mmap on RME9652 and HDSP drivers that didn't
 > set up properly.  Actually those driver do use the buffers allocated
 > in a standard way, and the proper calls should fix the breakage.
 > 
 > Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
 > Cc: <stable@vger.kernel.org>
 > Signed-off-by: Takashi Iwai <tiwai@suse.de>
 > ---
 >  sound/pci/rme9652/hdsp.c    | 6 ++----
 >  sound/pci/rme9652/rme9652.c | 6 ++----
 >  2 files changed, 4 insertions(+), 8 deletions(-)
 > 
 > diff --git a/sound/pci/rme9652/hdsp.c b/sound/pci/rme9652/hdsp.c
 > index 8457a4bbc3df..b32a72e28917 100644
 > --- a/sound/pci/rme9652/hdsp.c
 > +++ b/sound/pci/rme9652/hdsp.c
 > @@ -4518,8 +4518,7 @@ static int snd_hdsp_playback_open(struct snd_pcm_substream *substream)
 >      snd_pcm_set_sync(substream);
 >  
 >          runtime->hw = snd_hdsp_playback_subinfo;
 > -    runtime->dma_area = hdsp->playback_buffer;
 > -    runtime->dma_bytes = HDSP_DMA_AREA_BYTES;
 > +    snd_pcm_set_runtime_buffer(substream, hdsp->playback_dma_buf);
 >  
 >      hdsp->playback_pid = current->pid;
 >      hdsp->playback_substream = substream;
 > @@ -4595,8 +4594,7 @@ static int snd_hdsp_capture_open(struct snd_pcm_substream *substream)
 >      snd_pcm_set_sync(substream);
 >  
 >      runtime->hw = snd_hdsp_capture_subinfo;
 > -    runtime->dma_area = hdsp->capture_buffer;
 > -    runtime->dma_bytes = HDSP_DMA_AREA_BYTES;
 > +    snd_pcm_set_runtime_buffer(substream, hdsp->capture_dma_buf);
 >  
 >      hdsp->capture_pid = current->pid;
 >      hdsp->capture_substream = substream;
 > diff --git a/sound/pci/rme9652/rme9652.c b/sound/pci/rme9652/rme9652.c
 > index f1aad38760d6..8036ed761d53 100644
 > --- a/sound/pci/rme9652/rme9652.c
 > +++ b/sound/pci/rme9652/rme9652.c
 > @@ -2279,8 +2279,7 @@ static int snd_rme9652_playback_open(struct snd_pcm_substream *substream)
 >      snd_pcm_set_sync(substream);
 >  
 >          runtime->hw = snd_rme9652_playback_subinfo;
 > -    runtime->dma_area = rme9652->playback_buffer;
 > -    runtime->dma_bytes = RME9652_DMA_AREA_BYTES;
 > +    snd_pcm_set_runtime_buffer(substream, rme9652->playback_dma_buf);
 >  
 >      if (rme9652->capture_substream == NULL) {
 >          rme9652_stop(rme9652);
 > @@ -2339,8 +2338,7 @@ static int snd_rme9652_capture_open(struct snd_pcm_substream *substream)
 >      snd_pcm_set_sync(substream);
 >  
 >      runtime->hw = snd_rme9652_capture_subinfo;
 > -    runtime->dma_area = rme9652->capture_buffer;
 > -    runtime->dma_bytes = RME9652_DMA_AREA_BYTES;
 > +    snd_pcm_set_runtime_buffer(substream, rme9652->capture_dma_buf);
 >  
 >      if (rme9652->playback_substream == NULL) {
 >          rme9652_stop(rme9652);
 > -- 
 > 2.26.2
 > 
 
I applied the patch to kernel 5.13.8, but compilation fails with these errors:

sound/pci/rme9652/hdsp.c: In function ‘snd_hdsp_playback_open’:
sound/pci/rme9652/hdsp.c:4505:51: error: incompatible type for argument 2 of ‘snd_pcm_set_runtime_buffer’
 4505 |         snd_pcm_set_runtime_buffer(substream, hdsp->playback_dma_buf);
      |                                               ~~~~^~~~~~~~~~~~~~~~~~
      |                                                   |
      |                                                   struct snd_dma_buffer
In file included from sound/pci/rme9652/hdsp.c:23:
./include/sound/pcm.h:1154:70: note: expected ‘struct snd_dma_buffer *’ but argument is of type ‘struct snd_dma_buffer’
 1154 |                                               struct snd_dma_buffer *bufp)
      |                                               ~~~~~~~~~~~~~~~~~~~~~~~^~~~
sound/pci/rme9652/hdsp.c: In function ‘snd_hdsp_capture_open’:
sound/pci/rme9652/hdsp.c:4581:51: error: incompatible type for argument 2 of ‘snd_pcm_set_runtime_buffer’
 4581 |         snd_pcm_set_runtime_buffer(substream, hdsp->capture_dma_buf);
      |                                               ~~~~^~~~~~~~~~~~~~~~~
      |                                                   |
      |                                                   struct snd_dma_buffer
In file included from sound/pci/rme9652/hdsp.c:23:
./include/sound/pcm.h:1154:70: note: expected ‘struct snd_dma_buffer *’ but argument is of type ‘struct snd_dma_buffer’
 1154 |                                               struct snd_dma_buffer *bufp)
      |                                               ~~~~~~~~~~~~~~~~~~~~~~~^~~~
make[3]: *** [scripts/Makefile.build:273: sound/pci/rme9652/hdsp.o] Error 1
make[2]: *** [scripts/Makefile.build:516: sound/pci/rme9652] Error 2
make[1]: *** [scripts/Makefile.build:516: sound/pci] Error 2

I also patched and compiled 5.14-rc4, but got the same errors.

Next I tried cloning git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git.

The patch applied and compiled, but I get the same "does not support mmap" error when trying to play anything.

Let me know if there's any other info I can provide.

Thanks,
Jeff


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Kernel 5.13.6 breaks mmap with snd-hdsp module
  2021-08-07 22:51     ` Jeff Woods
@ 2021-08-08  7:01       ` Takashi Iwai
  2021-08-08 19:09         ` Jeff Woods
  0 siblings, 1 reply; 8+ messages in thread
From: Takashi Iwai @ 2021-08-08  7:01 UTC (permalink / raw)
  To: Jeff Woods; +Cc: Greg KH, alsa-devel, stable, regressions

On Sun, 08 Aug 2021 00:51:35 +0200,
Jeff Woods wrote:
> 
>  ---- On Sat, 07 Aug 2021 02:26:32 -0700 Takashi Iwai <tiwai@suse.de> wrote ----
>  > On Sat, 07 Aug 2021 10:16:47 +0200,
>  > Greg KH wrote:
>  > > 
>  > > On Sat, Aug 07, 2021 at 12:49:07AM -0700, Jeff Woods wrote:
>  > > > Specifically, commit c4824ae7db418aee6f50f308a20b832e58e997fd triggers the problem. Reverting this change restores functionality.
>  > > > 
>  > > > The device is an RME Multiface II, using the snd-hdsp driver.
>  > > > 
>  > > > Expected behavior: Device plays sound normally
>  > > > 
>  > > > Exhibited behavior: When a program attempts to open the device, the following ALSA lib error happens:
>  > > > 
>  > > > ALSA lib pcm_direct.c:1169:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access
>  > > > 
>  > > > This change hasn't affected my other computers with less esoteric hardware, so probably the problem lies with the snd-hdsp driver, but the device is unusable without reverting that commit.
>  > > > 
>  > > > I am available to test any patches for this issue.
>  > > 
>  > > Have you notified the developers involved in this change about this
>  > > issue?
>  > 
>  > No, it's a new report :)
>  > 
>  > > Adding them now...
>  > 
>  > Could you try the patch below?
>  > 
>  > 
>  > thanks,
>  > 
>  > Takashi
>  > 
>  > -- 8< --
>  > From: Takashi Iwai <tiwai@suse.de>
>  > Subject: [PATCH] ALSA: pci: rme: Fix mmap breakage
>  > 
>  > The recent change in the PCM core restricts the mmap of unknown buffer
>  > type, and this broke the mmap on RME9652 and HDSP drivers that didn't
>  > set up properly.  Actually those driver do use the buffers allocated
>  > in a standard way, and the proper calls should fix the breakage.
>  > 
>  > Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
>  > Cc: <stable@vger.kernel.org>
>  > Signed-off-by: Takashi Iwai <tiwai@suse.de>
>  > ---
>  >  sound/pci/rme9652/hdsp.c    | 6 ++----
>  >  sound/pci/rme9652/rme9652.c | 6 ++----
>  >  2 files changed, 4 insertions(+), 8 deletions(-)
>  > 
>  > diff --git a/sound/pci/rme9652/hdsp.c b/sound/pci/rme9652/hdsp.c
>  > index 8457a4bbc3df..b32a72e28917 100644
>  > --- a/sound/pci/rme9652/hdsp.c
>  > +++ b/sound/pci/rme9652/hdsp.c
>  > @@ -4518,8 +4518,7 @@ static int snd_hdsp_playback_open(struct snd_pcm_substream *substream)
>  >      snd_pcm_set_sync(substream);
>  >  
>  >          runtime->hw = snd_hdsp_playback_subinfo;
>  > -    runtime->dma_area = hdsp->playback_buffer;
>  > -    runtime->dma_bytes = HDSP_DMA_AREA_BYTES;
>  > +    snd_pcm_set_runtime_buffer(substream, hdsp->playback_dma_buf);
>  >  
>  >      hdsp->playback_pid = current->pid;
>  >      hdsp->playback_substream = substream;
>  > @@ -4595,8 +4594,7 @@ static int snd_hdsp_capture_open(struct snd_pcm_substream *substream)
>  >      snd_pcm_set_sync(substream);
>  >  
>  >      runtime->hw = snd_hdsp_capture_subinfo;
>  > -    runtime->dma_area = hdsp->capture_buffer;
>  > -    runtime->dma_bytes = HDSP_DMA_AREA_BYTES;
>  > +    snd_pcm_set_runtime_buffer(substream, hdsp->capture_dma_buf);
>  >  
>  >      hdsp->capture_pid = current->pid;
>  >      hdsp->capture_substream = substream;
>  > diff --git a/sound/pci/rme9652/rme9652.c b/sound/pci/rme9652/rme9652.c
>  > index f1aad38760d6..8036ed761d53 100644
>  > --- a/sound/pci/rme9652/rme9652.c
>  > +++ b/sound/pci/rme9652/rme9652.c
>  > @@ -2279,8 +2279,7 @@ static int snd_rme9652_playback_open(struct snd_pcm_substream *substream)
>  >      snd_pcm_set_sync(substream);
>  >  
>  >          runtime->hw = snd_rme9652_playback_subinfo;
>  > -    runtime->dma_area = rme9652->playback_buffer;
>  > -    runtime->dma_bytes = RME9652_DMA_AREA_BYTES;
>  > +    snd_pcm_set_runtime_buffer(substream, rme9652->playback_dma_buf);
>  >  
>  >      if (rme9652->capture_substream == NULL) {
>  >          rme9652_stop(rme9652);
>  > @@ -2339,8 +2338,7 @@ static int snd_rme9652_capture_open(struct snd_pcm_substream *substream)
>  >      snd_pcm_set_sync(substream);
>  >  
>  >      runtime->hw = snd_rme9652_capture_subinfo;
>  > -    runtime->dma_area = rme9652->capture_buffer;
>  > -    runtime->dma_bytes = RME9652_DMA_AREA_BYTES;
>  > +    snd_pcm_set_runtime_buffer(substream, rme9652->capture_dma_buf);
>  >  
>  >      if (rme9652->playback_substream == NULL) {
>  >          rme9652_stop(rme9652);
>  > -- 
>  > 2.26.2
>  > 
>  
> I applied the patch to kernel 5.13.8, but compilation fails with these errors:

Oops, sorry, that was the patch for linux-next, and I forgot the
recent code change.  And it turned out not to be effective.

Below is another try.  Scratch the previous one (although it cannot
hurt), and try this one instead.


thanks,

Takashi

-- 8< --
From: Takashi Iwai <tiwai@suse.de>
Subject: [PATCH] ALSA: pcm: Fix mmap breakage without explicit buffer setup

The recent fix c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
restricts the mmap capability only to the drivers that properly set up
the buffers, but it caused a regression for a few drivers that manage
the buffer on its own way.

For those with UNKNOWN buffer type (i.e. the uninitialized / unused
substream->dma_buffer), just assume that the driver handles the mmap
properly and blindly trust the hardware info bit.

Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
 sound/core/pcm_native.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
index 09c0e2a6489c..71323d807dbf 100644
--- a/sound/core/pcm_native.c
+++ b/sound/core/pcm_native.c
@@ -251,7 +251,10 @@ static bool hw_support_mmap(struct snd_pcm_substream *substream)
 
 	switch (substream->dma_buffer.dev.type) {
 	case SNDRV_DMA_TYPE_UNKNOWN:
-		return false;
+		/* we can't know the device, so just assume that the driver does
+		 * everything right
+		 */
+		return true;
 	case SNDRV_DMA_TYPE_CONTINUOUS:
 	case SNDRV_DMA_TYPE_VMALLOC:
 		return true;
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: Kernel 5.13.6 breaks mmap with snd-hdsp module
  2021-08-08  7:01       ` Takashi Iwai
@ 2021-08-08 19:09         ` Jeff Woods
  2021-08-09  6:50           ` Greg KH
  2021-08-09  6:55           ` Takashi Iwai
  0 siblings, 2 replies; 8+ messages in thread
From: Jeff Woods @ 2021-08-08 19:09 UTC (permalink / raw)
  To: Takashi Iwai; +Cc: Greg KH, alsa-devel, stable, regressions

 ---- On Sun, 08 Aug 2021 00:01:16 -0700 Takashi Iwai <tiwai@suse.de> wrote ----
 > On Sun, 08 Aug 2021 00:51:35 +0200,
 > Jeff Woods wrote:
 > > 
 > >  ---- On Sat, 07 Aug 2021 02:26:32 -0700 Takashi Iwai <tiwai@suse.de> wrote ----
 > >  > On Sat, 07 Aug 2021 10:16:47 +0200,
 > >  > Greg KH wrote:
 > >  > > 
 > >  > > On Sat, Aug 07, 2021 at 12:49:07AM -0700, Jeff Woods wrote:
 > >  > > > Specifically, commit c4824ae7db418aee6f50f308a20b832e58e997fd triggers the problem. Reverting this change restores functionality.
 > >  > > > 
 > >  > > > The device is an RME Multiface II, using the snd-hdsp driver.
 > >  > > > 
 > >  > > > Expected behavior: Device plays sound normally
 > >  > > > 
 > >  > > > Exhibited behavior: When a program attempts to open the device, the following ALSA lib error happens:
 > >  > > > 
 > >  > > > ALSA lib pcm_direct.c:1169:(snd1_pcm_direct_initialize_slave) slave plugin does not support mmap interleaved or mmap noninterleaved access
 > >  > > > 
 > >  > > > This change hasn't affected my other computers with less esoteric hardware, so probably the problem lies with the snd-hdsp driver, but the device is unusable without reverting that commit.
 > >  > > > 
 > >  > > > I am available to test any patches for this issue.
 > >  > > 
 > >  > > Have you notified the developers involved in this change about this
 > >  > > issue?
 > >  > 
 > >  > No, it's a new report :)
 > >  > 
 > >  > > Adding them now...
 > >  > 
 > >  > Could you try the patch below?
 > >  > 
 > >  > 
 > >  > thanks,
 > >  > 
 > >  > Takashi
 > >  > 
 > >  > -- 8< --
 > >  > From: Takashi Iwai <tiwai@suse.de>
 > >  > Subject: [PATCH] ALSA: pci: rme: Fix mmap breakage
 > >  > 
 > >  > The recent change in the PCM core restricts the mmap of unknown buffer
 > >  > type, and this broke the mmap on RME9652 and HDSP drivers that didn't
 > >  > set up properly.  Actually those driver do use the buffers allocated
 > >  > in a standard way, and the proper calls should fix the breakage.
 > >  > 
 > >  > Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
 > >  > Cc: <stable@vger.kernel.org>
 > >  > Signed-off-by: Takashi Iwai <tiwai@suse.de>
 > >  > ---
 > >  >  sound/pci/rme9652/hdsp.c    | 6 ++----
 > >  >  sound/pci/rme9652/rme9652.c | 6 ++----
 > >  >  2 files changed, 4 insertions(+), 8 deletions(-)
 > >  > 
 > >  > diff --git a/sound/pci/rme9652/hdsp.c b/sound/pci/rme9652/hdsp.c
 > >  > index 8457a4bbc3df..b32a72e28917 100644
 > >  > --- a/sound/pci/rme9652/hdsp.c
 > >  > +++ b/sound/pci/rme9652/hdsp.c
 > >  > @@ -4518,8 +4518,7 @@ static int snd_hdsp_playback_open(struct snd_pcm_substream *substream)
 > >  >      snd_pcm_set_sync(substream);
 > >  >  
 > >  >          runtime->hw = snd_hdsp_playback_subinfo;
 > >  > -    runtime->dma_area = hdsp->playback_buffer;
 > >  > -    runtime->dma_bytes = HDSP_DMA_AREA_BYTES;
 > >  > +    snd_pcm_set_runtime_buffer(substream, hdsp->playback_dma_buf);
 > >  >  
 > >  >      hdsp->playback_pid = current->pid;
 > >  >      hdsp->playback_substream = substream;
 > >  > @@ -4595,8 +4594,7 @@ static int snd_hdsp_capture_open(struct snd_pcm_substream *substream)
 > >  >      snd_pcm_set_sync(substream);
 > >  >  
 > >  >      runtime->hw = snd_hdsp_capture_subinfo;
 > >  > -    runtime->dma_area = hdsp->capture_buffer;
 > >  > -    runtime->dma_bytes = HDSP_DMA_AREA_BYTES;
 > >  > +    snd_pcm_set_runtime_buffer(substream, hdsp->capture_dma_buf);
 > >  >  
 > >  >      hdsp->capture_pid = current->pid;
 > >  >      hdsp->capture_substream = substream;
 > >  > diff --git a/sound/pci/rme9652/rme9652.c b/sound/pci/rme9652/rme9652.c
 > >  > index f1aad38760d6..8036ed761d53 100644
 > >  > --- a/sound/pci/rme9652/rme9652.c
 > >  > +++ b/sound/pci/rme9652/rme9652.c
 > >  > @@ -2279,8 +2279,7 @@ static int snd_rme9652_playback_open(struct snd_pcm_substream *substream)
 > >  >      snd_pcm_set_sync(substream);
 > >  >  
 > >  >          runtime->hw = snd_rme9652_playback_subinfo;
 > >  > -    runtime->dma_area = rme9652->playback_buffer;
 > >  > -    runtime->dma_bytes = RME9652_DMA_AREA_BYTES;
 > >  > +    snd_pcm_set_runtime_buffer(substream, rme9652->playback_dma_buf);
 > >  >  
 > >  >      if (rme9652->capture_substream == NULL) {
 > >  >          rme9652_stop(rme9652);
 > >  > @@ -2339,8 +2338,7 @@ static int snd_rme9652_capture_open(struct snd_pcm_substream *substream)
 > >  >      snd_pcm_set_sync(substream);
 > >  >  
 > >  >      runtime->hw = snd_rme9652_capture_subinfo;
 > >  > -    runtime->dma_area = rme9652->capture_buffer;
 > >  > -    runtime->dma_bytes = RME9652_DMA_AREA_BYTES;
 > >  > +    snd_pcm_set_runtime_buffer(substream, rme9652->capture_dma_buf);
 > >  >  
 > >  >      if (rme9652->playback_substream == NULL) {
 > >  >          rme9652_stop(rme9652);
 > >  > -- 
 > >  > 2.26.2
 > >  > 
 > >  
 > > I applied the patch to kernel 5.13.8, but compilation fails with these errors:
 > 
 > Oops, sorry, that was the patch for linux-next, and I forgot the
 > recent code change.  And it turned out not to be effective.
 > 
 > Below is another try.  Scratch the previous one (although it cannot
 > hurt), and try this one instead.
 > 
 > 
 > thanks,
 > 
 > Takashi
 > 
 > -- 8< --
 > From: Takashi Iwai <tiwai@suse.de>
 > Subject: [PATCH] ALSA: pcm: Fix mmap breakage without explicit buffer setup
 > 
 > The recent fix c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
 > restricts the mmap capability only to the drivers that properly set up
 > the buffers, but it caused a regression for a few drivers that manage
 > the buffer on its own way.
 > 
 > For those with UNKNOWN buffer type (i.e. the uninitialized / unused
 > substream->dma_buffer), just assume that the driver handles the mmap
 > properly and blindly trust the hardware info bit.
 > 
 > Fixes: c4824ae7db41 ("ALSA: pcm: Fix mmap capability check")
 > Cc: <stable@vger.kernel.org>
 > Signed-off-by: Takashi Iwai <tiwai@suse.de>
 > ---
 >  sound/core/pcm_native.c | 5 ++++-
 >  1 file changed, 4 insertions(+), 1 deletion(-)
 > 
 > diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c
 > index 09c0e2a6489c..71323d807dbf 100644
 > --- a/sound/core/pcm_native.c
 > +++ b/sound/core/pcm_native.c
 > @@ -251,7 +251,10 @@ static bool hw_support_mmap(struct snd_pcm_substream *substream)
 >  
 >      switch (substream->dma_buffer.dev.type) {
 >      case SNDRV_DMA_TYPE_UNKNOWN:
 > -        return false;
 > +        /* we can't know the device, so just assume that the driver does
 > +         * everything right
 > +         */
 > +        return true;
 >      case SNDRV_DMA_TYPE_CONTINUOUS:
 >      case SNDRV_DMA_TYPE_VMALLOC:
 >          return true;
 > -- 
 > 2.26.2
 > 
 > 

I applied the patch to 5.13.9, and it did indeed solve the problem.

Thank you very much!

For future reference, if I am reporting an issue with stable and I know the
commit that caused it, should I contact the committer directly *and* cc the
stable and regressions list?

I'm trying to keep protocol and not spam things up too much.

Thanks,
Jeff


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Kernel 5.13.6 breaks mmap with snd-hdsp module
  2021-08-08 19:09         ` Jeff Woods
@ 2021-08-09  6:50           ` Greg KH
  2021-08-09  6:55           ` Takashi Iwai
  1 sibling, 0 replies; 8+ messages in thread
From: Greg KH @ 2021-08-09  6:50 UTC (permalink / raw)
  To: Jeff Woods; +Cc: Takashi Iwai, alsa-devel, stable, regressions

On Sun, Aug 08, 2021 at 12:09:38PM -0700, Jeff Woods wrote:
> 
> For future reference, if I am reporting an issue with stable and I know the
> commit that caused it, should I contact the committer directly *and* cc the
> stable and regressions list?

Yes, that would be great to do.

thanks,

greg k-h

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Kernel 5.13.6 breaks mmap with snd-hdsp module
  2021-08-08 19:09         ` Jeff Woods
  2021-08-09  6:50           ` Greg KH
@ 2021-08-09  6:55           ` Takashi Iwai
  1 sibling, 0 replies; 8+ messages in thread
From: Takashi Iwai @ 2021-08-09  6:55 UTC (permalink / raw)
  To: Jeff Woods; +Cc: Greg KH, alsa-devel, stable, regressions

On Sun, 08 Aug 2021 21:09:38 +0200,
Jeff Woods wrote:
> 
> I applied the patch to 5.13.9, and it did indeed solve the problem.
> 
> Thank you very much!

Great, now I pushed the fix to for-linus branch, to be included in
5.14-rc6.

> For future reference, if I am reporting an issue with stable and I know the
> commit that caused it, should I contact the committer directly *and* cc the
> stable and regressions list?

Involving those relevant parties at the first place is always good.
IMO, it doesn't matter who is in Cc and who is in To.  The point is to
reduce the unnecessary hop and latency, so that developers can react
quickly.


Thanks!

Takashi

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2021-08-09  6:55 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-07  7:49 Kernel 5.13.6 breaks mmap with snd-hdsp module Jeff Woods
2021-08-07  8:16 ` Greg KH
2021-08-07  9:26   ` Takashi Iwai
2021-08-07 22:51     ` Jeff Woods
2021-08-08  7:01       ` Takashi Iwai
2021-08-08 19:09         ` Jeff Woods
2021-08-09  6:50           ` Greg KH
2021-08-09  6:55           ` Takashi Iwai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).