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. >
