Hi,
On Fri, 4 Nov 2022, Takashi Iwai wrote:
> On Fri, 04 Nov 2022 15:56:50 +0100, Kai Vehmanen wrote:
> > Looking at 5.15 code, the fallback looks very different, but
> > in fallback we still use the DMA mapping API via snd_dma_dev_alloc()
> > so even if we go to fallback path, mapping is still ok.
> >
> > Any ideas which way this should be fixed? Given the many changes
> > I thought it's better to ask early on the list about this.
>
> Hrm, that's a tough issue. Basically if dma_alloc_noncontiguous()
> fails, it's really out of memory -- at least under the situation where
> IOMMU is enabled. The fallback path was introduced for the case where
> there is no IOMMU and noncontiguous allocation fails from the
> beginning.
follow-up to this problem. It turns out there was additional problem
with dma_alloc_noncontiguous that led to ENOMEM much more frequently
than in the past. This required following:
- your rework in 5.16 to sound/core/memalloc.c for x86 DMA SG
- IOMMU/DMAR enabled for the device
- CONFIG_DMA_REMAP=n (default 'n' on most/all x86 systems before 5.18)
... with above combination, iommu_dma_ops in drivers/iommu/dma-iommu.c
were not defined for noncontiguous alloc/free, so the
dma_alloc_noncontiguous() in the end went back to plain
dma_common_alloc_pages() (single contiguous alloc), which would fail very
easily when system was in low-mem condition.
In 5.18, this patch was added
commit f5ff79fddf0efecca538046b5cc20fb3ded2ec4f
Author: Christoph Hellwig <hch@xxxxxx>
Date: Sat Feb 26 16:40:21 2022 +0100
dma-mapping: remove CONFIG_DMA_REMAP
... and this basicly fixes the issue again, even when IOMMU is enabled.
Br, Kai
