tkaiser Posted July 28, 2017 Posted July 28, 2017 Issue identified by Hardkernel folks with ODROID XU4 and 4.9 kernel: 'When a bunch of sequential data(inode) is being sent to the UAS driver, the UAS driver is increasing the DMA block memory allocation dynamically for more efficient ring-buffer management. But the Kernel coherent-pool memory size was limited at 256KB by default and it was not sufficient for the UAS drivers.' I added this as a temporary workaround to my OMV installation routine but would like to see this fixed on normal installations and also all affected boards too. I've to admit that I neither know how to determine coherent-pool memory size nor what potential downsides of increasing this are. Also no idea how to apply a fix (kernel patch or cmdline modification?)
zador.blood.stained Posted July 28, 2017 Posted July 28, 2017 3 minutes ago, tkaiser said: Also no idea how to apply a fix (kernel patch or cmdline modification?) Looks like the default value is set in arch/arm/mm/dma-mapping.c #define DEFAULT_DMA_COHERENT_POOL_SIZE SZ_256K so it can be patched instead of altering the kernel command line This is for 32-bit arm, 64-bit has the same default in arch/arm64/mm/dma-mapping.c
tkaiser Posted July 28, 2017 Author Posted July 28, 2017 8 minutes ago, zador.blood.stained said: dma-mapping.c So first step could be someone having all of our kernels checked out ( @Igor maybe? ) doing a quick find $sources -name dma-mapping.c | while read ; do grep DEFAULT_DMA_COHERENT_POOL_SIZE "$REPLY" ; done
Igor Posted August 20, 2017 Posted August 20, 2017 On 28. 7. 2017 at 5:32 PM, tkaiser said: So first step could be someone having all of our kernels checked out What can go wrong if we simply put this: coherent_pool=4M there?
zador.blood.stained Posted August 20, 2017 Posted August 20, 2017 3 minutes ago, Igor said: What can go wrong if we simply put this: coherent_pool=4M there? That any existing images won't get this since we are not updating the boot scripts. A kernel patch is relatively easy to add, easy to remove and the next kernel update will include the new coherent pool size.
tkaiser Posted August 20, 2017 Author Posted August 20, 2017 27 minutes ago, zador.blood.stained said: A kernel patch is relatively easy to add, easy to remove and the next kernel update will include the new coherent pool size. OMG, I totally forgot that we need one patch per kernel tree. So I would propose everyone of us touching UAS capable kernels simply adds the necessary increase from 256K to 1MB per kernel when changing anything the next days/weeks.
zador.blood.stained Posted August 20, 2017 Posted August 20, 2017 1 minute ago, tkaiser said: UAS capable kernels So how would you define a "uas capable kernel"? Starting with which version? Quick search suggests that UAS driver was added in 2.6.37: https://github.com/torvalds/linux/commit/115bb1ffa54c3934f3617bdd4e4dfc68b11e1e69
Igor Posted August 20, 2017 Posted August 20, 2017 Coherent pool is needed not just for UAS, but also for some wireless / DVB devices. So what to do?
tkaiser Posted August 20, 2017 Author Posted August 20, 2017 2 minutes ago, zador.blood.stained said: So how would you define a "uas capable kernel"? All next and dev kernels. Wrt default kernels my believe is we should look starting with 4.4. Ok, let's look in detail: Stricken through all platforms where UAS isn't working: linux-cubox-default.configlinux-meson-default.configlinux-meson64-default.config linux-mvebu-default.config linux-mvebu64-default.configlinux-odroidc1-default.configlinux-odroidc2-default.configlinux-odroidxu4-default.configlinux-pine64-default.config linux-rda8810-default.config linux-rk3328-default.config linux-rockchip-default.config linux-s500-default.configlinux-sun4i-default.config linux-sun5i-default.config linux-sun7i-default.config linux-sun8i-default.config linux-udoo-default.config linux-udoo-neo-default.config I think we don't need to care about rda8810 and s500? Last time I tested with i.MX6 platforms UAS was not available but that needs to be checked. With Armada 38x also no UAS but that needs to be checked too (though I think there aren't that many reasons to maintain default kernel for Clearfogs anyway). I will check later with EspressoBin. And someone else has to test with MiQi/Tinkerboard.
TonyMac32 Posted August 20, 2017 Posted August 20, 2017 3 hours ago, tkaiser said: I will check later with EspressoBin. And someone else has to test with MiQi/Tinkerboard. I'll let that other Dev with a Tinker Board take care of it.
TonyMac32 Posted August 21, 2017 Posted August 21, 2017 Is there an indication that SZ_1M is enough? Synolgoy: https://forum.synology.com/enu/viewtopic.php?t=109025 It looks like 1024k was too small for DVB transport in their case, I find this of interest as I can see an OMV setup with TV tuner being a popular use case (personally biased). I can patch it, although determining if it worked is another matter. I can not, for what it's worth, come up with any downside to increasing it, unless of course it cuts too much into available RAM.
zador.blood.stained Posted August 21, 2017 Posted August 21, 2017 7 hours ago, Igor said: I am 3/4 done with patches. It should be SZ_2M instead of SZ_2048K - the latter is not a predefined constant. 1
silentcreek Posted September 4, 2017 Posted September 4, 2017 Has this issue been reported upstream? I couldn't find a bug report on bugzilla.kernel.org, yet I didn't search in the mailing lists. The issue sounds like something that should be solved upstream rather than in a handful of packages or distributions.
tkaiser Posted September 4, 2017 Author Posted September 4, 2017 24 minutes ago, silentcreek said: Has this issue been reported upstream? I don't think so.
Recommended Posts