ASoC/ALSA Out of Memory Issue

[Alex Roberts]

I think I solved my issue. I reserved a block of memory for dma via
device tree following
/Documentation/devicetree/bindings/linux/reserved-memory.txt

Thanks,
Alex.

On Tue, Jul 27, 2021 at 10:05 PM Alex Roberts <arob109 at gmail.com> wrote:
>
> It get's -ENOMEM.. which appears to be returned by the imx-sdma driver
> when it attempts to allocate memory with the dma_alloc_coherent(...)
> function. This seems to get called through a chain of functions
> starting back to pcm_dmaengine.c > snd_dmaengine_pcm_trigger(...),
> under the SNDDRV_PCM_TRIGGER_START case which calls
> dmaengine_pcm_prepare_and_submit(...)... then
> dmaengine_prep_dma_cyclic(...).. which will call
> device_prep_dma_cyclic(...). In my case, I'm running on an NXP
> IMX8M-Quad, hence hte imx-sdma driver.
>
> Alex.
>
> On Tue, Jul 27, 2021 at 11:26 AM Takashi Iwai <tiwai at suse.de> wrote:
> >
> > On Mon, 26 Jul 2021 17:07:52 +0200,
> > Alex Roberts wrote:
> > >
> > > Hello,
> > >
> > > I am developing a dummy codec to interface with an 8-channel, 24-bit
> > > ADC. I've got it working on an NXP imx8m through the fsl_sai driver on
> > > kernel 5.4.85. I can capture all 8 channels at varying sample rates
> > > using arecord, and I've verified correct data capture via opening the
> > > resulting .wav file in Audacity. The problem I am having is that
> > > occasionally, upon starting arecord - after a fresh power cycle - I
> > > get an out of memory error. Other times I get an out of memory after a
> > > non-deterministic period of capture. Starting capture again also
> > > reports out of memory, but if I wait several minutes and start capture
> > > it will start recording again. A power cycle usually helps, but as
> > > stated earlier, not 100% of the time.
> >
> > Do you mean that application gets -ENOMEM error from API, or the
> > system exhausts the memory?  The former is often some buffer
> > management issue (e.g. the buffer perallocation didn't happen and yet
> > the dynamic allocation failed), but the latter is rather about the
> > memory leaks.
> >
> >
> > Takashi
> >
> > > I'm trying to track down where the oom error is coming from, but
> > > haven't had much luck. My colleague tried running arecord with
> > > valgrind to check for memory leaks and nothing of note was observed.
> > > My suspicion is there's something going on with allocated memory for
> > > DMA, like fragmentation starts to happen and it can't get a contiguous
> > > region for operation. Reserving a larger pool - either via device tree
> > > or kernel cmdline arguments in the bootoader - did not seem to help.
> > >
> > > Another thought is that it's a boundary/alignment issue due to the
> > > 24-bit data, and the error is the result of trying to allocate a chunk
> > > of memory for DMA that doesn't align.
> > >
> > > I'm very new to ALSA dev with some exposure to kernel dev in general,
> > > so please correct me if I'm wrong or completely mis-understanding
> > > something.
> > >
> > > Any suggestions on where I should / how I can debug this memory error?
> > >
> > > Thanks,
> > > Alex.
> > >
> > > PS: Previously sent this to just alsa-devel mailing list on 7/21, but
> > > never saw it show up in the archives. Here is more info since then:
> > >
> > > The goal is 8-channel, 96k sampling rate. I've reduced sampling rate
> > > and still have the issue. Reducing down to 4-channels helps, but
> > > haven't tested long term enough to evaluate by how much.
> > >
> > > Narrowed it down to device_prep_dma_cyclic(..) returning NULL within
> > > dmaengine_prep_dma_cyclic(..)..... still tracing through source to
> > > learn exactly what is going on.
> > >