On Mon, 25 Apr 2022 14:49:35 +0200, P9ter Ujfalusi wrote:
On 25/04/2022 15:28, Peter Ujfalusi wrote:
From: Peter Ujfalusi peter.ujfalusi@gmail.com
If the dma_alloc_noncontiguous() fails in snd_dma_noncontig_alloc() we are taking a fallback path which should be taken into account on the free path since the way to free the two type of allocations are not the same.
Fixes: 925ca893b4a6 ("ALSA: memalloc: Add fallback SG-buffer allocations for x86") Signed-off-by: Peter Ujfalusi peter.ujfalusi@gmail.com
Hi Takashi,
I'm not sure about thisa as I can not get my systems to use the fallback, but in theory this shiuld be done, no?
RIght, this is not needed as on the free path the callback is picked based on the dmab->dev.type, so it should be picking the correct free after all.
Please this patch.
Yes, the type got overwritten at switching to the fallback, so your change is superfluous.
Since you have introduced the fallback, I believe there are cases when it is taken and it might be related to some strange memory allocation errors happening in SOF during firmware loading, like: https://github.com/thesofproject/linux/issues/3609 https://github.com/thesofproject/linux/issues/3584 https://github.com/thesofproject/linux/issues/3530
Still these reports are real and somehow they are pointing to dma allocation issues.
Hrm, the fallback got backported to 5.17.4, so it might have been fixed already?
Yes, it should be. Let me know if the problem still persists even after the fallback support is backported to stable kernels.
thanks,
Takashi