On Tue, 6 Sep 2022, Laurent Vivier wrote: > Le 06/09/2022 à 17:52, Andreas Schwab a écrit : > > On Sep 06 2022, Eero Tamminen wrote: > > > >> Hi, > >> > >> On 6.9.2022 4.46, Stephen Walsh wrote: > >>> [ 3.110000] Call Trace: [<00354d80>] panic+0xc4/0x246 > >>> [ 3.110000] [<00355744>] _printk+0x0/0x18 > >>> [ 3.110000] [<00355756>] _printk+0x12/0x18 > >>> [ 3.110000] [<001ed30c>] strlen+0x0/0x14 > >>> [ 3.110000] [<0051054a>] mount_block_root+0x17a/0x194 > >>> [ 3.110000] [<001ed268>] strncmp+0x0/0x34 > >>> [ 3.110000] [<005105ac>] mount_root+0x48/0x14e > >>> [ 3.110000] [<005105d6>] mount_root+0x72/0x14e > >>> [ 3.110000] [<00008001>] atari_get_hardware_list+0x6d/0x3e0 > >> > >> This seems a bit odd line for kernel boot on Amiga. > > > > It's a false match (0x8001 can be anything). > > >
Expanding a little on what Andreas said above: Linux/m68k doesn't produce precise backtraces. What gets printed is any value found on the stack that could possibly be interpreted as an instruction pointer i.e. any address within a kernel code segment. > Stack corruption? > No, i's not an oops, it's normal behaviour: [ 3.110000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) This expected, and it is not the crash that was originally reported. Regarding the oops that was originally reported, the kernel already told us why it crashed: [ 0.000000] Ignoring memory chunk at 0x7800000:0x800000 before the first chunk [ 0.000000] Fix your bootloader or use a memfile to make use of this area! Hence Geert's questions aimed at figuring out what's going on with the bootloader. > 0x8001 looks like > > uapi/asm/bootinfo-amiga.h:#define BI_AMIGA_AUTOCON 0x8001 /* AutoConfig > device */ > By the time the kernel gets to mounting the rootfs, the stack frame generated by amiga_parse_bootinfo() has been clobbered many times over.
