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?)

 

 

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

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

 

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?

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.

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.

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

Coherent pool is needed not just for UAS, but also for some wireless / DVB devices. So what to do?

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.config
linux-meson-default.config
linux-meson64-default.config
linux-mvebu-default.config
linux-mvebu64-default.config
linux-odroidc1-default.config
linux-odroidc2-default.config
linux-odroidxu4-default.config
linux-pine64-default.config
linux-rda8810-default.config
linux-rk3328-default.config
linux-rockchip-default.config
linux-s500-default.config
linux-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.

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.  

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.

I am 3/4 done with patches. 

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.

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.

24 minutes ago, silentcreek said:

Has this issue been reported upstream?

 

I don't think so.