On Thu, Nov 09, 2017 at 09:36:39AM +0900, Joonsoo Kim wrote:

On Wed, Nov 08, 2017 at 04:11:13PM -0800, Tony Lindgren wrote:

quoted

* Joonsoo Kim [off-list ref] [171109 00:05]:

quoted

On Wed, Nov 08, 2017 at 08:34:13AM -0800, Tony Lindgren wrote:

quoted

* Joonsoo Kim [off-list ref] [171108 07:43]:

quoted

On Tue, Nov 07, 2017 at 07:48:42AM -0800, Tony Lindgren wrote:

quoted

So it seems the issue is currently at the atomic_pool_init()
related code?

Yes, your test showed it although I can't find any clue in
atomic_pool_init().

Could you test updated branch?

https://github.com/JoonsooKim/linux/tree/cma-debug4-next-20180901

There are two relevant commits.

arm/dma: stop dma allocation before __dma_alloc_remap()
arm/dma: disable atomic pool after dma allocation

atomic pool initialization will be done partially to check
exact point of failure. These are brain-dead commits however I have no
idea what's going on here until now. :/

OK that booted, dmesg output below. Hopefully that provides
you with some more clues.

Thanks!

Could you let me know which one is booted? Both of them? or just top
commit ("arm/dma: stop dma allocation before __dma_alloc_remap()")?

Oh OK. Only the top commit boots.

Okay! I will try to analyze!

Could you test following two commits on my updated branch?

"arm/dma: vmalloc area allocation"
"arm/dma: defer atomic pool initialization"

I suspect that changed virtual address of the sram due to early
__dma_alloc_remap() call causes the problem and above two commits test
this theory.

Thanks.