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@xxxxxxxxx>
> >
> > 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@xxxxxxxxx>
> > ---
> > 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
