On 10/06/2015 11:45 PM, Matt Campbell wrote: > Hi All, > > I've been trying to track down a kernel crash I've been getting when > closing ALSA devices. There is a race condition between the bottom half > interrupt handler for the DMA system (dmaengine_pcm_dma_complete in > pcm_dmaengine.c) and the releasing of the sub-stream resources it receives > as an argument (when snd_pcm_release is called). An older thread from 2013 > discussed this to a good extent so I wont go into the details here. I've > been unable to track down either a patch to fix this or even a good > solution that I could implement. I've spent a couple days trying to think > of an elegant solution and come up with nothing so far. Any input would be > appreciated. > > Link to original thread: > http://mailman.alsa-project.org/pipermail/alsa-devel/2013-October/067111.html > > It's worth nothing that the original thread points out how this can arise > on multi-core systems. In my case I'm on a single core system, but with the > real-time patch enabled and the userspace ALSA thread running at a higher > priority than the kernel's tasklet thread which can reproduce this almost > 100% of the time. Hi, The answer is still the same. This is an inherent issue with the DMAengine API that needs to be fixed by adding a synchronization primitive that allows consumers to make sure that all completion tasklets have stopped running. Unfortunately this wasn't implemented yet, but I need this in other places outside of ASoC and it's on my TODO list and I'll hopefully get to it in the next 2 months. But in your case on a single CPU system it could also be an issue with the DMA controller driver itself not properly stopping the transfer when dma_terminate_all() is called. - Lars -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
