Hi Mark, On Thu, 14 Jul 2022 at 19:09, Mark Rutland <mark.rutland@xxxxxxx> wrote: > > On Thu, Jul 14, 2022 at 02:06:28PM +0100, Mark Rutland wrote: > > > ... and I've just reproduced the issue by running the script from a different > > directory, since apprarently the semihosting interface just grabs the file from > > the current directory. > > > > I'm pretty sure this means that *something* is clobbering the Image early on > > during boot, and the semihisting loading happens to refresh it. > > I had a go with my own kernel built from my arm64/traps/rework branch: > > https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/traps/rework > > ... and Naresh's config: > > https://builds.tuxbuild.com/2BnQMpJj3kDTJXoCwd2pY5gW9CN/config > > When *only* using the initial loading into memory, that blows up in stackdepot > and with a subsequent bogus pointer dereference (full log below), and when > loaded via semihosting that just works. Note that my kernel is based on the > arm64 for-next/core branch, which itself is based on v5.19-rc3. > > My failing kernel Image is ~47M, as is Naresh's original Image. When using > smaller Images (as large as 43M so far), I don't see any issues. > > I also note that if I enable KASAN_OUTLINE, the kernel is so big that it > clobbers the DTB, and cannot be booted. So this looks liek a problem with tha > arbitrary placement / limits chosen for U-Boot being too small, and this is not > a kernel bug. Now I have understood the reason. > Naresh, please can you fix your boot flow before reporting any further issues? Yes. > This sort of corruption will manifest in a number of ways, and we need to rule > that out for any other bug reports. Any further reports I will do needful initial investigation. - Naresh
