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@lst.de 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