Jump to content

Recommended Posts

Posted

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

 

 

Posted
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

Posted
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

 

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

Posted
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.

Posted
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.

Posted

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

Posted
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.

Posted
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.  :P

Posted

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.

Posted

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.

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines