Re: [alsa-devel] unload Audio drivers while playback stream is active case kernel crash
Hi On 01/14/2015 05:15 PM, Lars-Peter Clausen wrote: On 01/14/2015 08:43 AM, Takashi Iwai wrote: At Tue, 13 Jan 2015 21:54:12 +, Mark Brown wrote: On Tue, Jan 13, 2015 at 06:24:44PM +0100, Takashi Iwai wrote: Wang, Jiada (ESD) wrote: I am using i.MX6Q sabreSD board, which have imx_wm892 machine driver, wm8962 codec and SSI CPU DAI, I got Kernel crash when unloading audio drivers (playback stream is active) modprobe -r snd_soc_imx_wm8962 modprobe -r snd_soc_fsl_ssi modprobe -r snd_soc_wm8962 The root problem is that you can unload the module while playing. The corresponding module refcounts should have been increased during used. Do we miss [try_]module_get() somewhere in ASoC? That doesn't help, users can still forcibly unbind the driver at runtime without loading the module - and there's always the potential for actually hotpluggable hardware. The teardown paths should be able to cope somewhat gracefully. The module refcount has to be handled while being used for stopping module unload. That's irrelevant from the dynamic unbinding support itself. Of course, the module refcount doesn't save the world, but it's the right fix for this particular scenario. Refcounting won't help in this case. The issue is caused by a delayed work item that gets launched when the PCM stream is stopped. So if you decrease the refcount when the stream is stopped you still have a window where it is possible to remove the module while the work is still being scheduled. And while we do flush the scheduled work when we remove the ASoC card this is done before snd_card_free() is called. So when snd_card_free() is called it gets re-scheduled again. I think the correct fix is to add a snd_card_disconnect() at the very top of soc_cleanup_card_resources(). when stream is active, snd_card_disconnect() will trigger pcm_close() be executed by another thread, we can't ensure the pcm_close() is executed before the rest of soc_cleanup_card_resources(). - Jiada - Lars -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] unload Audio drivers while playback stream is active case kernel crash
Hi On 01/14/2015 10:43 PM, Fabio Estevam wrote: On Wed, Jan 14, 2015 at 10:57 AM, Lars-Peter Clausen wrote: My personal opinion on this is that disallowing module removal while a driver registered by the module when is in use, while there is no technical reason to do so, is a anti-feature. Whether in ALSA or elsewhere. But looking at the source it seems that this is a core feature of ALSA and at least for the card module itself it will do the ref-counting when a stream is started/stopped. And we even support setting the owner of a card in ASoC. It's just that pretty much no ASoC card driver bothers to set the owner field in the snd_soc_card struct. So this particular problem can be fixed by updating the imx-wm8962 driver to set the owner field. Thanks, Lars_Peter. This fixes the issue: root@freescale /$ modprobe -r snd_soc_imx_wm8962 modprobe: can't unload module snd_soc_imx_wm8962: Resource temporarily unavailable Will send a patch with your suggestion soon. I think by set owner field in imx_wm8962 machine driver can fix the crash I saw on sabreSD board, but as this is a generic issue which I suppose should exist on other boards with different machine drivers. Can we have a more generic fix to this issue? Or shall we set owner field for all machine drivers? Thanks, Jiada -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 11/15] serial: imx: initialized DMA w/o HW flow enabled
Hello Sebastian On 04/13/2015 05:06 PM, Sebastian Andrzej Siewior wrote: On Mon, Apr 13, 2015 at 04:40:15PM +0900, jiwang wrote: Hi Sebastian Hi Jiada, My question is how was this tested. Before your patch none of my boards were using DMA because RTS/CTS is not in use and this was a key requirement. Now SDMA goes crazy. Is there a SDMA firmware required for this to work? We tested the patch set with our modified kernel tree, and I find upstream kernel is not building SDMA firmware, I will submit another patch to add it. Please make sure it is tagged stable. There is no hint that this is required and as of it now, it breaks v4.0. Due to missing of SDMA firmware, uart sdma mode is broken, but it is uncovered by this commit on your environment. One question, where do you have the firmware from? I picked the one from FSL's v3.10 SDK and I ended up with FIFO-overflows so it was clearly the wrong one (and the built-in SDMA firmware does not work as expected as you mentioned). I got sdma firmware from FSL kernel tree. Is this firmware only required the imx6 series or also for older versions like imx5? the firmware only supports imx6 series, AFAIK, I checked with Freescale imx6 support team, due to licensing issue, I am not entitled to upstream FSL SDMA firmware. so seems currently disable SDMA support for uart is our only option at the moment. Thanks, Jiada Thanks, Jiada Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 11/15] serial: imx: initialized DMA w/o HW flow enabled
Hi Sebastian On 04/09/2015 09:00 PM, Sebastian Andrzej Siewior wrote: On 2014-12-09 18:11:32 [+0900], Jiada Wang wrote: From: Anton Bondarenko DMA mode for UART can be used even w/o HW flow control with RTS/CTS. So it need to be initialized and enabled earlier. Signed-off-by: Anton Bondarenko Signed-off-by: Jiada Wang How was this tested? I read you used the Sambe IMX6Q. I have here the Wandboard which is IMX6D and a PBAB01 which is IMX6Q. Both have the same issue with this patch, that is once DMA is enabled I receive the data in question plus one extra byte which is 0x00. That extra byte was not part of transaction. After that, the SDMA driver is handling interrupts like crazing and feeding one byte data (usually 0x00 but sometimes 0x02 not sure if this new or whatever was there before) to the core. Those one byte transaction are bogus of course. My question is how was this tested. Before your patch none of my boards were using DMA because RTS/CTS is not in use and this was a key requirement. Now SDMA goes crazy. Is there a SDMA firmware required for this to work? We tested the patch set with our modified kernel tree, and I find upstream kernel is not building SDMA firmware, I will submit another patch to add it. Thanks, Jiada Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
