On 10/19/2021 7:37 AM, Catalin Marinas wrote: >>> I could help to confirm if it hangs right in the early boot somewhere if needed. >> >> The kernel config and a log of working kernel would help to start with. http://lsbug.org/tmp/ > > I don't think there's much in the log other than the EFI stub above. > >>> start_kernel() >>> setup_arch() >>> paging_init() >>> map_mem() >>> memblock_mark_nomap( > > Is this actual trace? It would be good to know where exactly it got > stuck. No, I did not confirm anything yet. There is going to take a while to figure out the exactly location that hang since even the early console was not initialized yet. Any suggestion on how to debug in this case? > >> So we have kmemleak_free_part_phys() here. > > I wonder whether the memblock_mark_nomap() here is too early for > kmemleak. We don't have the linear map created, though it shouldn't be > an issue as the kernel sections are mapped. Also I think > delete_object_part() in kmemleak.c would bail out early as there > shouldn't be any prior memblock_alloc for this range. >
