On Wed, Sep 16, 2020 at 2:25 PM Nick Desaulniers <ndesaulniers@xxxxxxxxxx> wrote: > > Also, it looks like the GCC build of milbeaut_m10v_defconfig fails to > boot for me in QEMU; so maybe not just a Clang bug (or maybe, more > than one bug). (or maybe one of my command line params to QEMU is > wrong). > > Stepping through start_kernel(), the call to setup_arch() seems to > hang in qemu. For both GCC and Clang builds. A breakpoint in panic() > never gets hit. Looks like the deepest I can get is: > > Looks like: > #0 memblock_alloc_try_nid (size=108, align=4, min_addr=0, max_addr=0, > nid=-1) at mm/memblock.c:1601 > #1 0xc060f0b4 in memblock_alloc (size=<optimized out>, > align=<optimized out>) at ./include/linux/memblock.h:409 > #2 cma_init_reserved_mem (base=1543503872, size=67108864, > order_per_bit=0, name=0xc04b9240 "reserved", res_cma=0xc07ccbdc > <dma_contiguous_default_area>) at mm/cma.c:190 > #3 0xc060f2c0 in cma_declare_contiguous_nid (base=1543503872, > size=67108864, limit=1610612736, alignment=8388608, order_per_bit=0, > fixed=false, name=0xc04b9240 "reserved", > res_cma=0xc07ccbdc <dma_contiguous_default_area>, nid=-1) at mm/cma.c:352 > #4 0xc0608cb6 in cma_declare_contiguous (alignment=<optimized out>, > order_per_bit=<optimized out>, name=<optimized out>, > res_cma=<optimized out>, fixed=<optimized out>, > limit=<optimized out>, size=<optimized out>, base=<optimized out>) > at ./include/linux/cma.h:28 > #5 dma_contiguous_reserve_area (size=<optimized out>, base=<optimized > out>, limit=<optimized out>, res_cma=0xc07ccbdc > <dma_contiguous_default_area>, fixed=false) > at kernel/dma/contiguous.c:201 > #6 0xc0608d22 in dma_contiguous_reserve (limit=<optimized out>) at > kernel/dma/contiguous.c:171 > #7 0xc0604584 in arm_memblock_init (mdesc=0xc061bfe8 > <__mach_desc_GENERIC_DT.35641>) at arch/arm/mm/init.c:230 > #8 0xc060302c in setup_arch (cmdline_p=<optimized out>) at > arch/arm/kernel/setup.c:1132 > #9 0xc06007d2 in start_kernel () at init/main.c:857 > > there's a call to memset that seems to hang. I wonder if memset() was > defined in terms of __builtin_memset, which oft can result in infinite > loops? (IIRC there's an AEABI related memset; this kind of thing has > hit android userspace before). > > (gdb) layout asm > > shows that the source call to memset is transformed into a call to mmioset. > > (gdb) bt > #0 mmioset () at arch/arm/lib/memset.S:19 > #1 0xc060e2dc in memblock_alloc_try_nid (size=108, align=<optimized > out>, min_addr=0, max_addr=0, nid=-1) at mm/memblock.c:1602 > #2 0xc060f0b4 in memblock_alloc (size=<optimized out>, > align=<optimized out>) at ./include/linux/memblock.h:409 > #3 cma_init_reserved_mem (base=1543503872, size=67108864, > order_per_bit=0, name=0xc04b9240 "reserved", res_cma=0xc07ccbdc > <dma_contiguous_default_area>) at mm/cma.c:190 > #4 0xc060f2c0 in cma_declare_contiguous_nid (base=1543503872, > size=67108864, limit=1610612736, alignment=8388608, order_per_bit=0, > fixed=false, name=0xc04b9240 "reserved", > res_cma=0xc07ccbdc <dma_contiguous_default_area>, nid=-1) at mm/cma.c:352 > #5 0xc0608cb6 in cma_declare_contiguous (alignment=<optimized out>, > order_per_bit=<optimized out>, name=<optimized out>, > res_cma=<optimized out>, fixed=<optimized out>, > limit=<optimized out>, size=<optimized out>, base=<optimized out>) > at ./include/linux/cma.h:28 > #6 dma_contiguous_reserve_area (size=<optimized out>, base=<optimized > out>, limit=<optimized out>, res_cma=0xc07ccbdc > <dma_contiguous_default_area>, fixed=false) > at kernel/dma/contiguous.c:201 > #7 0xc0608d22 in dma_contiguous_reserve (limit=<optimized out>) at > kernel/dma/contiguous.c:171 > #8 0xc0604584 in arm_memblock_init (mdesc=0xc061bfe8 > <__mach_desc_GENERIC_DT.35641>) at arch/arm/mm/init.c:230 > #9 0xc060302c in setup_arch (cmdline_p=<optimized out>) at > arch/arm/kernel/setup.c:1132 > #10 0xc06007d2 in start_kernel () at init/main.c:857 > > Using `si` in gdb, it looks like we maybe hit an exception vector? > x 1202 .section .vectors, "ax", %progbits > > x > x 1203 .L__vectors_start: > > x > x 1204 W(b) vector_rst > > x > x 1205 W(b) vector_und > > x > x 1206 W(ldr) pc, .L__vectors_start + 0x1000 > > x > x >1207 W(b) vector_pabt > > Is the last thing I see, then `si` stops working. Not sure if `pabt` > is a recognizable acronym to anyone more familiar with ARM? > > Happens regardless of your series, FWIW. It seems this is affecting the ARCH=arm defconfig (regardless of toolchain) of linux-next today. I know you've warned me about testing on -next before... Maybe this is: https://lore.kernel.org/linux-next/20200916140437.GL2142832@xxxxxxxxxx/ ? That looks arm64 specific though. Maybe 32b ARM needs the same or a similar fix? Oh man, this boots, total shot in the dark: diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c index 45f9d5ec2360..7118b98c1f5f 100644 --- a/arch/arm/mm/init.c +++ b/arch/arm/mm/init.c @@ -226,9 +226,6 @@ void __init arm_memblock_init(const struct machine_desc *mdesc) early_init_fdt_reserve_self(); early_init_fdt_scan_reserved_mem(); - /* reserve memory for DMA contiguous allocations */ - dma_contiguous_reserve(arm_dma_limit); - arm_memblock_steal_permitted = false; memblock_dump_all(); } @@ -248,6 +245,9 @@ void __init bootmem_init(void) */ sparse_init(); + /* reserve memory for DMA contiguous allocations */ + dma_contiguous_reserve(arm_dma_limit); + /* * Now free the memory - free_area_init needs * the sparse mem_map arrays initialized by sparse_init() -- Thanks, ~Nick Desaulniers
